SIO Patch in Emulator - documentation available?

[Andre]

Hi,

I am looking for a documentation of the SIO-patch "for fast disk access" (used with Atari emulators, e.g. in Atari800Win PLus 4.0). What does this patch alter in the normal OS SIO-routine?

Thanks for your help,

André

[ijor]

Hi Andre,

It doesn’t actually patch the SIO code. It just doesn’t run the SIO routines. When the emulator detects a disk access is requested to SIO, it directly accesses the file image bypassing the whole SIO protocol.

[Andre]

Hi!

It doesn’t actually patch the SIO code. It just doesn’t run the SIO routines. When the emulator detects a disk access is requested to SIO, it directly accesses the file image bypassing the whole SIO protocol.

You mean what is called "the patch" is actually "nothing"?

[ijor]

Well, it’s not exactly “nothing”, but patch is probably the wrong term. It’s actually more a trap operation.

When the “patch” is enabled the emulator inserts a seudo breakpoint at SIO entry point. When the breakpoint is triggered, the emulator takes control and processes the SIO command itself. The operation is then processed in the emulator context (and not in the Atari emulated context) at the full PC speed. The emulator inspects the SIO parameters and automatically xfers the data to/from the disk image from/to the Atari memory. Before restarting emulation, the 6502 registers and (I think) a few SIO variables are set as if the command was actually processed by SIO.

This is of course not fully compatible, and not only because of the faster timing.

[phsstpok]

Hi,

I am looking for a documentation of the SIO-patch "for fast disk access" (used with Atari emulators, e.g. in Atari800Win PLus 4.0). What does this patch alter in the normal OS SIO-routine?

Thanks for your help,

André

Download the source code and see for yourself.

OK, that's not such an easy thing to do, at least not for me. I'm pretty much C-language illiterate, but I tried.

I looked at the SIO routines and as far as I can tell (feel free to correct me if I'm wrong, anyone) the "SIO Patch" is actually an Un-patch. The SIO calls are never bypassed but when the "patch" is activated the false timing latencies get set to zero, well some of them do. The routines are free to run at full speed (PC speeds).

Note that I'm talkiing about the raw support handlers for the SIO routines. These are the routines that manipulate the physical PC hardware.

The actual Atari SIO handlers are of course part of the Atari OS ROMs plus a few additions from DOS in some cases, like RS232 handlers, and the PutSector (without verify), change density, etc. disk commands. These handlers are not altered by Atari800Win Plus, AFAIK.


Phsstpok

[ijor]

I looked at the SIO routines and as far as I can tell (feel free to correct me if I'm wrong, anyone) the "SIO Patch" is actually an Un-patch. The SIO calls are never bypassed but when the "patch" is activated the false timing latencies get set to zero, well some of them do. The routines are free to run at full speed (PC speeds).

No, this is not how the patch works. See the explanation in my previous post.

[phsstpok]

[See Update below]

I looked at the SIO routines and as far as I can tell (feel free to correct me if I'm wrong, anyone) the "SIO Patch" is actually an Un-patch. The SIO calls are never bypassed but when the "patch" is activated the false timing latencies get set to zero, well some of them do. The routines are free to run at full speed (PC speeds).

No, this is not how the patch works. See the explanation in my previous post.

Ah, I see now, well, not really but I'll take you word for it. Sorry, I should have read the whole thread before opening my big mouth (and putting my foot in it).

I can't seem to find the pseudo break point in the code that you speak of. However, I'd like to find it and understand the code and what's going on. The reason I want to do this is I wrote an impromptu sector copier in Action. It runs fine when the SIO Patch is disabled but when the patch is enabled it fails. By failing, I mean the program goes thorugh all the motions of copying the data but the destination ATR never actually gets updated. No I/O errors get reported on the virtual Atari during the process.

One strange thing I noticed, if I start the copier while the SIO Patch is disabled but then enable the patch when the copying is about halfway complete then it works. Switching any sooner it fails.

I verified successful runs using a file comparison program, PC based. The ATRs are exactly the same byte for byte.

I've also tested the copier using a real Atari plus APE for Windows with the same results. ATRs are exact.

I tried with real floppies too, same results. In this case I used an indirect method to compare results. I used WriteATR (pc utility) to copy each floppy to an ATR file on the PC. (It's a fast utility. About 50 seconds per SSDD disk). Again, both files are exactly the same.

Though my sector copier is extremely crude at the moment I'm confident it's not the program that is the source of my problem. All it's doing is SIO ReadSectors and PutSectors. I haven't been able to understand why it does not work with the SIO Patch enabled.

I'm suspecting that Atari800Win Plus is caching the output and then never writing the cache to the ATR. I'm going to test this idea by reading the sectors after writing them.

Sorry for getting off-topic and for my blunders. LOL!

[Update]
I found my problem. It was in my code but I'm not taking all the blame. LOL!

I'm just relearning programming and I wanted to play with SIO calls. I downloaded a shareware skeletal frame for setting up the DCB's. I just discovered a bug. Below is an excerpt from the ReadSector routine.

PROC ReadSector(BYTE drive, CARD secnum,buf)
_ddir=64 ;Read data
_dcmd=$52 ;Read sector command ('R)
_dbuf=buf
_sect=secnum
_ddev=$30+drive
_ddno=drive

Notice _ddev (Atari name - DDEVICE, $300) is wrong. It should be $31 for all disk drives. The WriteSector and PutSector routines have the same mistake.

What's funny is the code works, in a fashion. Feeding 1 for drive sets up the DCB correctly. _ddev becomes $31 and _ddno (DUNIT, $301) becomes $1. However, supplying 2 for drive yields $32 and $2, respectively. $32 is clearly wrong yet the code would run.

I could not figure out why both the Emulator and the real Atari sent the output to D3: instead of D2:. I thought I was just misunderstanding SIO calls for disk drives.

I assume the SIO Patch trapped the calls and ignored them. Not sure. I've done enough speculating lately.

Anway, now my modified code runs with/without the SIO patch enabled and I learned more than if I had been able to use the skeleton verbatim.


Phsstpok

[ijor]

I can't seem to find the pseudo break point in the code that you speak of.

It is applied at the main module (atari.c, I think), not at the sio module. It uses a function called "addEscape" or something like that. The SIO module does have the routine that actually performs the I/O when the patch is activated. IIRC it is called just "SIO".

Don't know why your sector copier fails. Might be an emulator bug, might be an incompatibility with the patch. Your idea of doing a verification sounds good. It verification works ok, then it is more likely an emulator bug.

[phsstpok]

See my update to my previous post.

[ijor]

Notice _ddev (Atari name - DDEVICE, $300) is wrong. It should be $31 for all disk drives. The WriteSector and PutSector routines have the same mistake.

I assume the SIO Patch trapped the calls and ignored them. Not sure. I've done enough speculating lately.

The exact behavior depends if you are calling the disk handler ($E453) or SIO ($E459).

The disk handler ignores whatever you put in $300, it will force it to $31. SIO doesn’t ignore it. It adds both values (minus one).

Checked the code and it’s a buglet in the emulator. The “patch” routines assumes $300 should have $31, which is strictly not correct.

Btw, looks like the "skeleton" was designed to call the disk handler and not SIO. Otherwise a couple of other variables should be set (such as the timeout).

[Andre]

Checked the code and it’s a buglet in the emulator.

Which emulator are you referring to? Atari800win?

[ijor]

Which emulator are you referring to? Atari800win?

The bug is in the Atari800 core. So it will be present on any emulator based on the core (Atari800win, winplus, etc).

[phsstpok]

Notice _ddev (Atari name - DDEVICE, $300) is wrong. It should be $31 for all disk drives. The WriteSector and PutSector routines have the same mistake.

I assume the SIO Patch trapped the calls and ignored them. Not sure. I've done enough speculating lately.

The exact behavior depends if you are calling the disk handler ($E453) or SIO ($E459).

The disk handler ignores whatever you put in $300, it will force it to $31. SIO doesn’t ignore it. It adds both values (minus one)

Checked the code and it’s a buglet in the emulator. The “patch” routines assumes $300 should have $31, which is strictly not correct.

Btw, looks like the "skeleton" was designed to call the disk handler and not SIO. Otherwise a couple of other variables should be set (such as the timeout).

I left out much from the skeleton. It's not that long but too long for a message. The DCB setup was exactly as you see it though.

The routines are definitely calling the SIO vector, $E459, and yes I discovered the need for the missing parameters. My own code has a timeout value (is 3 seconds enough in the real world for reads and writes?) and a buffer size (128 or 256).

The reason I thought I wanted this skeleton is it has support for SpartaDOS' high speed SIO. There is a routine to check for the existence of Sparta's LSIO handler and will use the appropriate vector rather than the SIO vector. The code will use the standard SIO vector when the other is not available.

Turns out I don't have a need this feature after all. I only have an Atari 800 and SpartaDOS requires an XL/XE. I've been using BWDOS, which uses a SpartaDOS compatible disk format, but BWDOS does not include a high speed SIO handler.

My little program is really just an exercize for me to learn SIO calls and the Action! language. Although, someone on usenet was looking for a sector copier that can copy 65,535 sectors, for hard drive partition backups. I've already copied 30,000 sectors but that was using the SIO patch and Atari800Win Plus (4.0, beta 4).

I can't imagine doing it with a real Atari and real drives. 65,535 sectors would seemingly take hours! Of course if one needs a backup then time isn't that important.

Can you explain to a NOOB (me) the intracacies of DDEVICE and DUNIT parameters? Everything I read says DDEVICE would always be $31 for any disk drive and that individual drives are selected using the DUNIT parameter. However, as I learned, and you stated, DDEVICE does modify drive selection. You said the SIO routines add both values (minus one). I don't doubt it but I don't understand why. I mean it seems overly complicated.

Thanks for your help and for your patience with me.


Phsstpok

[ijor]

At the SIO protocol level, the device identifier is a single byte. So SIO must combine the value in $300 with the one in $301 in a single byte. As I said, it adds both values and subtracts one. Then, for example, $31 + 1 – 1 = $31, which is the identifier for disk drive one. The convention when calling SIO is the one you mention, but any other combination that will yield the same result (say, $2F and $03) will work exactly the same.

This is, at least, how standard OS behaves. There is no guarantee that a custom ROM will produce the same effect. But most, if not all, custom ROMs will try to mimic the Atari original ones as much as possible.

SpartaDos doesn’t require an XL/XE. There might be some versions that do, don’t remember for sure, but definitely not all.

The standard timeout used by the disk handler is, IIRC, 7 seconds. I don’t remember which setting DOS uses, and might be different across different DOS versions. I would say that 3 seconds is more than enough for normal operation. But if the drive retries for some reason, it might be too close. You don’t loose anything by using a bigger timeout. If there is a disk error, the drive will report it soon enough. And if the drive itself is turned off, your timeout settings are ignored anyway.

[phsstpok]

At the SIO protocol level, the device identifier is a single byte. So SIO must combine the value in $300 with the one in $301 in a single byte. As I said, it adds both values and subtracts one. Then, for example, $31 + 1 – 1 = $31, which is the identifier for disk drive one. The convention when calling SIO is the one you mention, but any other combination that will yield the same result (say, $2F and $03) will work exactly the same.

Now I understand.

This is, at least, how standard OS behaves. There is no guarantee that a custom ROM will produce the same effect. But most, if not all, custom ROMs will try to mimic the Atari original ones as much as possible.

SpartaDos doesn’t require an XL/XE. There might be some versions that do, don’t remember for sure, but definitely not all.

I have 3.2X (or 32 X or something like that). I'll look into other versions if I feel the need. Thanks for the tip.

The standard timeout used by the disk handler is, IIRC, 7 seconds. I don’t remember which setting DOS uses, and might be different across different DOS versions. I would say that 3 seconds is more than enough for normal operation. But if the drive retries for some reason, it might be too close. You don’t loose anything by using a bigger timeout. If there is a disk error, the drive will report it soon enough. And if the drive itself is turned off, your timeout settings are ignored anyway.

Once again, thanks.

You've been very helpful.

Too bad about the SIO patch having incorrect behavior. On the other hand, that's a lot better than what I was thinking.


Phsstpok