Highspeed SIO at 110kbit - testers needed

[HiassofT]

I've been working on my highspeed SIO patch again, this time my goal was to break the ~80kbit limit.

 

I did several tests with a modified version of AtariSIO and a 16C950 card in my PC. Both my PAL and NTSC 800XLs were able to handle 110kbit (pokey divisor 1), if Antic DMA is turned off even 126kbit (pokey divisor 0) is possible :-)

 

Now I'm seeking for some people who would be willing to test this with the Atarimax SIO2PC USB interface or other devices that are supposed to support higher bitrates.

 

I also did some tests with my SIO2SD but it wouldn't run faster than ~88kbit (pokey divisor 3). The faster speed settings neither worked with my patch nor with Copy 2000.

 

Here's the link to my current testing version: http://www.horus.com/~hias/tmp/hipatch-090212.zip

 

If you're impatient: run the "HISIORI.COM" (or the "HISIOI.COM") from the hipatch.atr and check out if it works.

 

The hipatch.atr contains a bunch of new patches, all ending with an "I" (decide for yourself if this means "increased speed", "insane" or whatever :-). The versions without the "I" at the end are (more or less) identical to the old patches and will only go up to max. ~80kbit.

 

You'll also find 3 further ATRs with diagnostic code in the zip-file:

"diag.atr" continuously reads the sectors from D2: (note: the disk/image in D2 must be in double density/180k!) and stops if there's a transmission error. Then it outputs the current timestamp plus the error code.

 

"diag-nodma.atr" is identically to "diag.atr", but it disables Antic DMA during the tests.

 

"diag-ext.atr" does the same tests, but has debugging code enabled and outputs some more information (for example command frame retries etc.).

 

If you'd like to do some quick tests, use either the "diag.atr" or the "diag-nodma.atr" files.

 

Now for some background information:

 

The reason the old patch couldn't get beyond the ~80kbit limit was because the immediate VBI handler used too much time. If it kicked in an overrun occurred and a byte was lost.

 

The highsio versions with the "I" at the end patch the NMI handler of the OS and use a shorter code if the CRITIC flag is set. If CRITIC is not set, the original OS code is used. The new code removes atract mode handling (if CRITIC is set), so please be warned and don't blame me if you ruin your CRT, otherwise it's identical to the original code: it increments the clock counter at $12..$14 and also handles the first system timer (used for SIO timeout handling). For more details have a look at the "fastnmi.src" file.

 

Please note that there might be other factors that limit the maximum achievable SIO speed:

 

First of all, keep your SIO chain as short as possible. The more devices you have in your chain, the higher the capacitive load will be and this may lead to errors at high speed. Ideally, only connect one device directly to your Atari.

 

Next thing: there are some 1nf capacitors in parallel to the SIO lines inside (almost) all Ataris and also in the 1050s. They might limit maximum speed as well.

 

Last thing: it depends on your device. Not only on the firmware (which is responsible for timing), but also on the parts used to build it. For example: I was able to run 110kbit with 2 1050s in my SIO chain with a SIO2PC interface using the MAX232 and also had the capacitors in my 800XL. OTOH there were reports from people having problems with a XF551 at 38kbit. Unless you don't want to modify the internals of your device stick to the first 2 factors: short SIO chain and remove the caps :-)

 

I'd be glad to read some reports from you, no matter if it's "great, I'm the speed king" or "holy shit, I'm stuck at ~60kbit" stuff :-)

 

so long,

 

Hias

[doctorclu]

Oh man, if you could get this working with a term program, I would be SO THERE! I would love to move along on the BBS's faster than 19.2K on the Atari 800.

 

Does this only with the SIO2PC USB Atarimax cart or are there other things this works with?

[Marius]

Oh man, if you could get this working with a term program, I would be SO THERE! I would love to move along on the BBS's faster than 19.2K on the Atari 800.

 

Does this only with the SIO2PC USB Atarimax cart or are there other things this works with?

 

This will never be possible on BBS-in. The BBS software on the host side is far too complicated to let it communicate on higer speeds. The BBS program I used wasn't even able to work with normal highspeed from disk.

 

Sorry

 

Marius

[HiassofT]

Oh man, if you could get this working with a term program, I would be SO THERE! I would love to move along on the BBS's faster than 19.2K on the Atari 800.

What do you exactly mean by that? Highspeed SIO with the terminal program or the BBS software? Or higher serial (terminal) speed with the terminal program or with the BBS software?

 

Basically my patch should work with terminal programs or the BBS software to increase SIO transfer rates, unless the R: handler or the SIO-to-serial interface (850 etc.) react allergic to those high speeds. If that's the case, please drop me a line so that I can have a look at it.

 

Does this only with the SIO2PC USB Atarimax cart or are there other things this works with?

Actually I'm not even sure if it works correctly with the Atarimax interface as I don't have one to test with :-)

 

You should be able to use the SIO2SD interface at higher speed, maybe even some other devices that I'm not aware of (I have neither a SIO2IDE nor a SIO2USB interface, and don't know how fast they'll go up in speed).

 

Serial SIO2PC interfaces might also be an option, but it depends on your serial adapter card and on the software you are using. For example my current AtariSIO development version works fine at 110 and 126kbit when using a 16C950 card (the code still needs some more testing, cleanup, extensions etc., but it works with my current setup).

 

so long,

 

Hias

[+Stephen]

I've been working on my highspeed SIO patch again, this time my goal was to break the ~80kbit limit.

 

I did several tests with a modified version of AtariSIO and a 16C950 card in my PC. Both my PAL and NTSC 800XLs were able to handle 110kbit (pokey divisor 1), if Antic DMA is turned off even 126kbit (pokey divisor 0) is possible :-)

 

***** BIG SNIP *****

 

I'd be glad to read some reports from you, no matter if it's "great, I'm the speed king" or "holy shit, I'm stuck at ~60kbit" stuff :-)

 

so long,

 

Hias

I will check this out tonight and report my findings. I can tell you that I get a consistent 110kbit transfer from my USB SIO2PC device when using the MyCopier disk copy program.

 

Stephen Anderson

[doctorclu]

I'll look into getting the AtariMax USB cart. This is interesting.

[_The Doctor__]

SIO2PC USB?

mine has been running at divisor 0x00 since I first got it.

only switching to divisor 2, 3 or 4 when using SpartaDos.

 

I've been working on my highspeed SIO patch again, this time my goal was to break the ~80kbit limit.

 

I did several tests with a modified version of AtariSIO and a 16C950 card in my PC. Both my PAL and NTSC 800XLs were able to handle 110kbit (pokey divisor 1), if Antic DMA is turned off even 126kbit (pokey divisor 0) is possible :-)

 

***** BIG SNIP *****

 

I'd be glad to read some reports from you, no matter if it's "great, I'm the speed king" or "holy shit, I'm stuck at ~60kbit" stuff :-)

 

so long,

 

Hias

I will check this out tonight and report my findings. I can tell you that I get a consistent 110kbit transfer from my USB SIO2PC device when using the MyCopier disk copy program.

 

Stephen Anderson

[+Stephen]

SIO2PC USB?

mine has been running at divisor 0x00 since I first got it.

only switching to divisor 2, 3 or 4 when using SpartaDos.

 

What OS are you using that let's you use divisors above 08? I am using the APE Warp OS that came with my 32-in-1 OS. But it won't do above 3XSIO (divisor 08). I set it higher, the OS reverts to single speed SIO. The only thing I fond that let it run flat out (01 was the best I coud get - I have a 130XE which might need the SIO caps removed) was one single disk copy utility.

 

Stephen Anderson

[+Stephen]

I've been working on my highspeed SIO patch again, this time my goal was to break the ~80kbit limit.

 

I did several tests with a modified version of AtariSIO and a 16C950 card in my PC. Both my PAL and NTSC 800XLs were able to handle 110kbit (pokey divisor 1), if Antic DMA is turned off even 126kbit (pokey divisor 0) is possible :-)

 

***** BIG SNIP *****

 

I'd be glad to read some reports from you, no matter if it's "great, I'm the speed king" or "holy shit, I'm stuck at ~60kbit" stuff :-)

 

so long,

 

Hias

I will check this out tonight and report my findings. I can tell you that I get a consistent 110kbit transfer from my USB SIO2PC device when using the MyCopier disk copy program.

 

Stephen Anderson

 

No luck so far. Trying to load the patch at divisors 02 and 01 cause the SIO2PC device to "crash". Ape reports it as disconnected, and the Atari cannot communicate. I have to unplg & replug the USB cable to re-initialize the device. It's late here, I will test more tomorrow.

 

Stephen Anderson

[HiassofT]

No luck so far. Trying to load the patch at divisors 02 and 01 cause the SIO2PC device to "crash". Ape reports it as disconnected, and the Atari cannot communicate. I have to unplg & replug the USB cable to re-initialize the device. It's late here, I will test more tomorrow.

This is strange. Sounds like the microcontroller in the SIO2PC interface locked up. Are you using the latest firmware version? Maybe Steve knows more about this.

 

BTW: Does the lockup also happen when you use Copy 2000 V2.41D? You can find the program in this ATR (filename is "COPY2000.COM").

 

so long,

 

Hias

[+Stephen]

No luck so far. Trying to load the patch at divisors 02 and 01 cause the SIO2PC device to "crash". Ape reports it as disconnected, and the Atari cannot communicate. I have to unplg & replug the USB cable to re-initialize the device. It's late here, I will test more tomorrow.

This is strange. Sounds like the microcontroller in the SIO2PC interface locked up. Are you using the latest firmware version? Maybe Steve knows more about this.

 

BTW: Does the lockup also happen when you use Copy 2000 V2.41D? You can find the program in this ATR (filename is "COPY2000.COM").

 

so long,

 

Hias

No lockup with that copier. It screams with divisor 01. I put my benchmarks up here. I got:

- 90KB SD/SS - 15.13 seconds = 5.947KB/sec

- 180KB DD/SS - 22.67 seconds = 7.94KB.sec

 

I will verify with Steve Tucker that I have the latest version of APE (I'm registered) and the latest firmware in the device.

 

Stephen Anderson

[raster/c.p.u.]

... I also did some tests with my SIO2SD but it wouldn't run faster than ~88kbit (pokey divisor 3).

Hi. I tried your testing programs with our SDrive device yesterday and results are the same. It works well with pokey divisor 3 (~88kbit), but not with faster speeds.

Greetings, raster/c.p.u.

[_The Doctor__]

I am using the sio2pc usb version, a 320k xe using regular old os with capacitors snipped from SIO in/out etc., and the software that ape provides. I went in to the configure section and set each device to it's highest speed, I set them to pokey timing and I am using ntsc machines. I was able to set some pal timings in the same general area and achieved similar results but was still using ntsc hardware. I had to slow it down to 2 3 or 4 when using different spartas, after consulting with the dlt crew it was stated that to keep compatible with happy and indus that the ceiling would be kept at that level. I use SpartaX on 1meg maxflash quite a bit.

You may need to update your 32 in one OS or snip the caps in your machine I removed mine long ago on ALL of my Atari's. In Out and I think one or two others. If you need me to yank the case, shielding off to take a look I will.

 

SIO2PC USB?

mine has been running at divisor 0x00 since I first got it.

only switching to divisor 2, 3 or 4 when using SpartaDos.

 

What OS are you using that let's you use divisors above 08? I am using the APE Warp OS that came with my 32-in-1 OS. But it won't do above 3XSIO (divisor 08). I set it higher, the OS reverts to single speed SIO. The only thing I fond that let it run flat out (01 was the best I coud get - I have a 130XE which might need the SIO caps removed) was one single disk copy utility.

 

Stephen Anderson

[+Larry]

I can confirm that I have been able to run at a divisor of 0 using APE to APE transfers with MyDos 4.50 and HISIOI.COM. This was in single or double density, and was successful on an NTSC XL and XE (caps. removed on the XE).

 

Using HISIO.COM, I can only get down to 5 in double density or 3 in single density. However, if a device is plugged into the ECI, then I have not been able to go any lower than the 5 and 3 figures quoted above, even when using HISIOI.COM. I can *almost* get 4 in double density, but not quite -- hangs once in a while. So with a HD plugged in, the transfers to APE are essentially where they have been using the previous patch or the Black Box drivers.

 

The RESET function works correctly, so long as the transfers have been successful. If a transfer has failed, then RESET crashes my system. Also, if using HISIO.COM, then the system will not boot if set below 5 (dd) or 3 (sd).

 

-Larry

[HiassofT]

... I also did some tests with my SIO2SD but it wouldn't run faster than ~88kbit (pokey divisor 3).

Hi. I tried your testing programs with our SDrive device yesterday and results are the same. It works well with pokey divisor 3 (~88kbit), but not with faster speeds.

Thanks for testing!

 

This is interesting: both devices are using an Atmel chip (mega32 on SIO2SD, mega8 on SDrive) and both seem to have a limit of ~88kbit.

 

Did anyone have success using a higher bitrate yet, maybe with some other software / highspeed code? Or maybe it has something to do with the UART in the Atmels?

 

I just did a test with my SIO2SD (configured at divisor 2) using the "diag-ext.atr": The SIO2SD receives the command frame (and also displays it), sends back an ACK and a COMPLETE, but then pokey reports a framing error after a few data bytes.

 

If you'd like to test it by yourself: first, try a disk image containing real data in D2:. With an empty test image I just got a timeout, but no framing error. Then start the test with diag-ext.atr.

 

After an error first the contents of $0300 ff are printed. The next line contains a timestamp, followed by 3 status bytes (there might be more lines with status bytes following).

 

The first byte is the current "phase" of my SIO code. Phase "0" is the command-frame phase when the code waits for an ACK. If you just got one line with a phase "0", then ignore it. The device usually just had to switch to the right speed. In read operations phase "3" is the data part, when the Atari waits for the data block from the device.

 

The second byte is the status code returned by the SIO code, just like in the standard SIO calls. "8A" means timeout, "8C" framing error, "8E" data overrung, "8F" checksum error.

 

The third byte is the last received ACK/NAK/COMPLETE/ERROR byte. You can ignore this, too.

 

In my test it looked like this:

31 02 52 8C 00 03 07 00 00 01 04 00  <-- SIO block for read sector 4 on D2:
014D8E.24: 00 8A 00				  <-- timeout waiting for command ACK, ignore
03 8C 43							 <-- framing error in data phase

so long,

 

Hias

[HiassofT]

I am using the sio2pc usb version, a 320k xe using regular old os with capacitors snipped from SIO in/out etc., and the software that ape provides.

What DOS and/or software are you using on your Atari (besides SDX)?

 

With the stock OS the SIO speed configured in APE doesn't matter at all - the stock OS will only use ~19kbit.

 

Of course if you use some other OS (like APE warp+, qmeg etc) or software (SpartaDos, my patch, ...) that enables highspeed SIO, the configured speed is important.

 

BTW: it's also quite easy to tell the SIO speed when listening to the SIO-beeps. Reading/writing a disk at pokey divisor 0 or 1 almost sounds like the "farting" when a drive is not found :-)

 

Have a look at Steve's video when using Copy 2000 at pokey divisor 0.

 

so long,

 

Hias

[HiassofT]

Hi Larry!

 

Thanks for your report (and also your PMs, the OS you attached looks OK)!

 

I can confirm that I have been able to run at a divisor of 0 using APE to APE transfers with MyDos 4.50 and HISIOI.COM. This was in single or double density, and was successful on an NTSC XL and XE (caps. removed on the XE).

This is also interesting. With AtariSIO I haven't been able to use divisor 0 without turning off DMA. But, well, fine :-)

 

Using HISIO.COM, I can only get down to 5 in double density or 3 in single density.

OK, this is what I expected.

 

However, if a device is plugged into the ECI, then I have not been able to go any lower than the 5 and 3 figures quoted above, even when using HISIOI.COM. I can *almost* get 4 in double density, but not quite -- hangs once in a while. So with a HD plugged in, the transfers to APE are essentially where they have been using the previous patch or the Black Box drivers.

I still have to investigate this issue. If the ECI/PBI device contains some (highspeed) SIO code (like the blackbox) this would be clear. But I'm still not sure why this fails with the KMK/JZ interface.

 

The RESET function works correctly, so long as the transfers have been successful. If a transfer has failed, then RESET crashes my system.

I haven't been able to reproduce this yet. If a SIO transfer fails at high speed, the code automatically retries it in standard speed. But this shouldn't have anything to do with a crash on RESET.

 

I have tried to do the following things:

- Configure AtariSIO to pokey divisor 1

- Boot MyDOS 4.50 (on my PAL 800XL with the stock OS

- Type "DOS" to enter the DUP

- Load HISIO.COM from D2:

- After that loading DUP.SYS takes a while, some highspeed transfers are OK, some others run into a timeout and are retried in standard speed. But after some 20 or 30 seconds the DUP was back.

- In DUP I can list the directories of D1: and D2:, but due to the failed transfers this takes somewhat longer

- I went back to basic and pressed reset, everything fine so far

- Then typed "DOS" to enter the DUP again (still takes quite some time)

- Listing directories works fine

- Pressed reset, got back to Basic

- Typed "DOS", was immediately back in the DUP

 

Could you please describe your steps that triggered the crash?

 

The only thing I can currently think of would be some other software that overwrites the reset-handler at the beginning of the stack area. But maybe I'm just missing something very obvious (programmers are often blind when it comes to finding bugs in their own code) :-)

 

Also, if using HISIO.COM, then the system will not boot if set below 5 (dd) or 3 (sd).

What do you mean with "boot"? Did you load HISIO.COM as (kind of) a AUTORUN.SYS?

 

In MyDOS I then entered "M" and "E477" which did a cold-boot and re-enabled the ROM OS, therefore reverting back to standard SIO speed.

 

so long,

 

Hias

[_The Doctor__]

The black box will overwrite/trap highsio unless you disable the dipswitch on the bb that activates the bb sio. So disable the BB's dip and you will find hisio may give another result.

Edited February 20, 2009 by _The Doctor__

[+JAC!]

Hello Hias,

 

Seems the VBI time spent is cirtical for all this. So I had a look at "FASTNMI.SRC" and had two ideas that might help to save 3 more cycles for the normal case:

- The CLD in the first line is not needed for the NMI core routine , it can be moved to a location right before the timout JMP without changing the semantics. This saves 2 cycles. And if the timeout occurs, these cycle won't be relevant.

- The section that tests for CDTMV1/2 running to zero could be speeded up by assuming that the timout normally fits into the low byte. I don't know who sets the timeout normally, but I assumme the high speed routine would to this.

 

Maybe it helps to oversome some of the timing problems, maybe not.

 

I have attached the modifed version of the source (untested, all done in Notepad ).

 

Regards, Peter/JAC!

fastnmi_2.txt

[HiassofT]

Hi Peter,

 

thanks for your ideas!

 

Seems the VBI time spent is cirtical for all this. So I had a look at "FASTNMI.SRC" and had two ideas that might help to save 3 more cycles for the normal case:

- The CLD in the first line is not needed for the NMI core routine , it can be moved to a location right before the timout JMP without changing the semantics. This saves 2 cycles. And if the timeout occurs, these cycle won't be relevant.

Yes, that's right. The CLD must also be added to the beginning of "?NODLI", but otherwise that's fine. I've added this to my code.

 

- The section that tests for CDTMV1/2 running to zero could be speeded up by assuming that the timout normally fits into the low byte. I don't know who sets the timeout normally, but I assumme the high speed routine would to this.

Unfortunately this assumption is not true. For standard disk IO (read/write sector etc.) the timeout is usually set to 7 seconds - the maximum timeout with a 1 byte counter would be some 5 seconds (PAL) or 4 seconds (NTSC). I also tried to optimize the counting code but didn't find a way so that it's still operating correctly (i.e.: like the standard OS). We have to keep in mind that this code could also be used by other programs, so changing it wouldn't be a good idea.

 

Another idea for speeding up the code would be to remove most of the JSRs (for example ?GETBYTE) and replace them with inlined code. But this would increase the code size significantly and the patch wouldn't fit into the $CC00-$CFFF range any more. But for other programs (maybe if someone wants to write yet another high-speed sector copier) this would still be a possibility. I can't tell for sure, but maybe ANTIC DMA could still work then at Pokey divisor 0.

 

so long & thanks again,

 

Hias

[+JAC!]

The section that tests for CDTMV1/2 running to zero could be speeded up by assuming that the timout normally fits into the low byte. I don't know who sets the timeout normally, but I assumme the high speed routine would to this

Unfortunately this assumption is not true. For standard disk IO (read/write sector etc.) the timeout is usually set to 7 seconds - the maximum timeout with a 1 byte counter would be some 5 seconds (PAL) or 4 seconds (NTSC).

 

The modification work of course correctly also with larger timeout value, but one cycle is saved only when the timeout is at most $00ff, which appears to be reasonable long time for me (at least for this experiment). And I though the routine which installs the patch could also set this timeout.

 

May I'll find the time to try this out on the realy machine and not in notepad soon

[Rybags]

Why are you assuming that DLIs are enabled?

 

Normal SIO disables them. Are you catering for software that gets around that?

 

Can't you just assume that DLIs won't be forced back on, and cut back the code to suit that.

[HiassofT]

Hi Rybags!

 

Why are you assuming that DLIs are enabled?

 

Normal SIO disables them. Are you catering for software that gets around that?

 

Can't you just assume that DLIs won't be forced back on, and cut back the code to suit that.

Are you sure about this? I couldn't find anything regarding DLIs in the OS source code. The SIO code only sets CRITIC to 1.

 

The NMI code of the OS checks for DLIs at the very beginning - before checking the CRITIC flag. In my code I changed this so that CRITIC also disables DLIs. Having DLIs enabled during very-high-speed SIO wouldn't be a wise idea. And since I don't know if DLIs are enabled or not, I thought it would be best to ignore them.

 

so long,

 

Hias

[Rybags]

I'm almost positive SIO sets NMIEN to $40... thus disabling DLIs.

 

I can remember working years ago on a game loading screen that I wanted a DLI for some jazzed up effects. Pretty sure I had to put a quick VB-I routine in as well to force the DLIs to be enabled.

 

ed - seems I was wrong.

 

That's a downer, since it could have been an easy way to save some cycles. I guess if you disable DLIs then, you have the problem that a whole lot of software could "break".

 

But... as your routine stands, it seems to add some overhead to DLIs, which could cause problems for some games/demos.

 

 

Something worth a try... I don't know if it'll work as I've never tried it myself:

Just dispense with the STA $D40F altogether.

 

Antic only holds NMI low for a certain period for DLIs, not sure if it's the same case with VBlank Interrupts. Might be worth a shot.

Edited March 6, 2009 by Rybags

[HiassofT]

Hi Rybags!

 

That's a downer, since it could have been an easy way to save some cycles. I guess if you disable DLIs then, you have the problem that a whole lot of software could "break".

 

But... as your routine stands, it seems to add some overhead to DLIs, which could cause problems for some games/demos.

OK, you are right. I hadn't thought about this before. I guess I'll change my code back so that it's conforming to the standard again - and just use the shorter VBI code when CRITIC is set.

 

Something worth a try... I don't know if it'll work as I've never tried it myself:

Just dispense with the STA $D40F altogether.

 

Antic only holds NMI low for a certain period for DLIs, not sure if it's the same case with VBlank Interrupts. Might be worth a shot.

Interesting idea! I'll think about it and do some tests later.

 

so long,

 

Hias