[See Update below]
ijor wrote:phsstpok wrote: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