AspeQt: Yet another SIO2PC/APE clone

[atari8warez]

Apparently /F switch is provided when a hardware exists but can not be detected (for reasons unknown to me). It then begs the question why is the hw can not be detected? If it is because of the hardware not conforming to "standards" then why does the driver has to provide a switch to override, the correct way would have been to ask the hardware designer to make it compatible. Otherwise if the driver can not detect the hardware because of it's own fault the correct way would have been to fix the driver instead of allowing for an override switch. I may be wrong but it seems to me that the driver is trying to be everything to every ARC design out there..

 

As I mentioned earlier I can not check for negative flag because the driver returns positive when no hardware exists and AspeCl would report this as a success.

 

I hope FJC is no longer at loss

Edited September 10, 2013 by atari8warez

[flashjazzcat]

As I mentioned earlier I can not check for negative flag because the driver returns positive when no hardware exists and AspeCl would report this as a success.

 

I hope FJC is no longer at loss

 

I remain at a loss because this is becoming farcical, Ray. What is the brick wall of incomprehension which is preventing you from absorbing these simple concepts (or at least they should be simple to a half-competent programmer)? Konrad has already adequately explained the reasoning behind the /F switch. It's a left-over from the driver testing and development stage, and its continued existence should not concern you at all. Once you discount this entirely irrelevant flag, the driver then returns the proper codes at all times: i.e. positive for success, and negative in the event of an error.

 

Now, what is the problem with that? Can you rationally explain to me why you cannot simply check for the negative flag?

Edited September 10, 2013 by flashjazzcat

[+Stephen]

Why do I think this will not end well

[atari8warez]

Now, what is the problem with that? Can you rationally explain to me why you cannot simply check for the negative flag?

 

If you bother to read my entire response to this issue you may see why I can't do it that way, I explained it twice already and I will not repeat it a third time. Besides did Conrad appoint you as his attorney, what is your beef?

 

By the way AspeCL will not change the way it does it's status check. If one driver does not work the same way all other drivers do then it is the driver that should be fixed. I will simply include a note in the AspeCL documentation about this odd situation so people do know what's happening.

Edited September 11, 2013 by atari8warez

[atari8warez]

Why do I think this will not end well

 

Because you have previous examples to refer back to. But don't worry the issue is closed for me so no more comments from me on this subject (to FJC that is).

Edited September 11, 2013 by atari8warez

[atari8warez]

Well, you should test for a positive/negative status, and not for a 0, because, as said above, the "success" code might officially be 0 or 1, and theoretically even 3. Of course, as I wrote above, "4" is most probably a bug in the driver. But as long as the state of the N flag returned is correct, that's a minor bug.

 

What do you exactly mean by "the success code might officially be 0 or 1, and theoretically even 3", what are the differences between those values?. Also as I said earlier even if i check for negative, there is at least one case where my check would not make sense, that is when there is no hardware present but the driver is loaded with the /F switch. If that was done for testing purposes the manual should state so and it doesn't. It just looks like some hardware can not be detected (for apparently some mysterious reason - actually not too mysterious to me but never mind that) so the user can rectify this situation using the /F switch at the expense of correct status monitoring (when there is no hardware and the driver is loaded).

Edited September 11, 2013 by atari8warez

[atari8warez]

For anyone who might care about conventions used for success/failure status monitoring in programming:

 

The parent and the child can have an understanding about the meaning of the exit statuses. For example, it is common programming practice for a child process to return zero to the parent signifying success.

 

To summarize:

 

C language

 

The C programming language allows programs exiting or returning from the main function to signal success or failure by returning an integer, or returning the macros EXIT_SUCCESS and EXIT_FAILURE. On Unix-like systems these are equal to 0 and 1 respectively.

 

Java

 

In Java, any method can call System.exit(int status), unless a security manager does not permit it. This will terminate the currently running Java Virtual Machine. "The argument serves as a status code; by convention, a nonzero status code indicates abnormal termination.

 

 

POSIX

 

POSIX-compatible systems typically use a convention of zero for success and non zero for error.

 

Windows

 

Succes indicated by a 0

 

 

My 30+ years of IT experience also tells me the conventions are as above, but who am I to know after all I am not a "half-competent programmer"

Edited September 11, 2013 by atari8warez

[+Stephen]

Well you can't really fault the Atari OS written in 6502 assembly in 1978 for not fully following C guidelines can you?

 

P.S.

I am ball-busting a tiny bit. I do agree (and code to) proper failure & success codes. However, I understand why in some circumstances, it works on Atari that negative flag = failure, and positive flag is "user-defined". Don't get so worked up - this is not industrial control code helping land a robot on Mars - it's software for a long dead platform.

 

P.P.S.

No need for chest thumping about your 30 years IT experience. I'm not spouting off here about how I am maintaining a half million line of code fully customizable management system being used by NASA now, am I.

[atari8warez]

No need for chest thumping about your 30 years IT experience. I'm not spouting off here about how I am maintaining a half million line of code fully customizable management system being used by NASA now, am I.

 

My comment wasn't for you and it's a response to an individual who is arrogant despite the fact that I was coding while he was still s**ting his pants. By the way the conventions were the same even in the 70's regardless of programming platform. If Atari didn't follow it does not mean we shouldn't either, even if it is a dead platform. After all if we keep inventing new hardware and software for it, might as well do it right.

 

 

Quote: "I'm not spouting off here about how I am maintaining a half million line of code fully customizable management system being used by NASA now, am I."

 

I've got to admit, you are one helluva patient guy, code maintenance was the reason why I quit my job and became self-employed, if I was going to do that might as well make better buck while doing it.

Edited September 11, 2013 by atari8warez

[flashjazzcat]

What a nob-head. Back on the block list, then.

[atari8warez]

What a nob-head. Back on the block list, then.

 

You better make up your mind but I am sure you will eventually be back because this is what's feeding you, you can't help to interject on subjects that are none of your business, in some rather unpleasant ways.

Edited September 11, 2013 by atari8warez

[w1k]

hello, whats new with R: support?

[atari8warez]

Not much I am afraid, I am still not back to coding.

[SIO2]

I am using the AspeQT software on an XP PC with the monitor, keyboard and mouse normally removed. I have AspeQT mount some folders from removable media. That way I can change the files that are available to the ATARI by placing the removable media in my laptop, organizing the files then returning it to the PC file server. It is nice not to have all the ugly PC desktop hardware in my Atari space.

 

This works fine as long as I do not remove the removable media while the XP machine is running. If I do remove it, the folders are dismounted and will not remount without user intervention meaning that I have to attach my monitor, keyboard and mouse. So, it works fine as long as I remember not to "hot swap" removable media. Sometimes though, I forget.

 

Is there a way to cause AspeQT to remount the removable media folders that I had set up without user intervention or, could there be a removable media mode added to AspeQT where I could create on removable media, folders (such as Atari1,Atari2...Atari8) that correspond to slots/drives in AspeQT and that would be mounted at least at boot up if they can't be made to hot swap?

 

Perhaps this already exists and I am just not aware of it.

 

Thank you for AspeQT by the way. It is a great software.

 

 

[atari8warez]

I am using the AspeQT software on an XP PC with the monitor, keyboard and mouse normally removed. I have AspeQT mount some folders from removable media. That way I can change the files that are available to the ATARI by placing the removable media in my laptop, organizing the files then returning it to the PC file server. It is nice not to have all the ugly PC desktop hardware in my Atari space.

 

This works fine as long as I do not remove the removable media while the XP machine is running. If I do remove it, the folders are dismounted and will not remount without user intervention meaning that I have to attach my monitor, keyboard and mouse. So, it works fine as long as I remember not to "hot swap" removable media. Sometimes though, I forget.

 

Is there a way to cause AspeQT to remount the removable media folders that I had set up without user intervention or, could there be a removable media mode added to AspeQT where I could create on removable media, folders (such as Atari1,Atari2...Atari8) that correspond to slots/drives in AspeQT and that would be mounted at least at boot up if they can't be made to hot swap?

 

Perhaps this already exists and I am just not aware of it.

 

Thank you for AspeQT by the way. It is a great software.

 

 

I've never tried using removable media with AspeQt so I am not totally aware what exactly is happening when one hot-swaps media on removable drives. I know however that AspeQt will not currently automatically mount any unmounted folder or ATR, except when it is first starting.

 

There is a way to mount/unmount disk images (but not folders) remotely using AspeCL client module. I can add remote folder mount/unmount functionality to AspeCl so that you can also handle folders remotely. Or I can add remote re-start command to restart AspeQT remotely so that folders and disk images can be remounted. Modifiying AspeQt itself to automatically remount removable media folders is a bit more involved and I have to look at it before I can decide how to implement it.

[atari8warez]

I've just tested AspeQt v0.8.8 on a Windows 7 64 bit machine using a USB stick. Created a folder on the USB stick called Atari, copied an ATR file into it and mounted the folder with AspeQt, doing a DIR on that virtual drive on the Atari computer shows the ATR file in the folder. I then removed the USB stick and observed AspeQt noticing that the folder Atari is still mounted, doing a DIR on it on the Atari computer however now shows an empty directory of that folder. This is as I expected. AspeQt after mounting a folder always re-reads the contents of the folder when that folder is accessed by the Atari computer, thus it shows an empty directory after the USB stick is removed.

 

I then copied some more ATR files into that Atari folder using my laptop and re-inserted the USB stick to the PC. When I did a DIR on the Atari I can now see the old ATR file as well as new ones I added to the folder with my laptop.

 

Now, I do not know how you have a different experience, maybe an XP machine acts differently then a Win 7 machine, but I have to verify that by repeating my test on my XP PC.

 

 

EDIT: I also tested this with my XP machine and I have the same behavior there. Re-insert the removable media with new files in it and do a DIR from the Atari, new files show-up on the folder. This means I need more info from you to duplicate the problem (if any). What kind of removable media are you using?

Edited December 8, 2013 by atari8warez

[Van]

Although AspeQt may already have your needed functionality, you might also like to look into VNC. If you have a lan setup and your 'Atari server' laptop can be connected to it, VNC's client/server can allow you to administer it via a remote desktop. I have run headless Win98 PCs this way for simple network storage in the past. Of course you may be able to use the native XP Remote Desktop also, but I've never used it so not too sure how to set it up.

Yogi.

[SIO2]

I've just tested AspeQt v0.8.8 on a Windows 7 64 bit machine using a USB stick. Created a folder on the USB stick called Atari, copied an ATR file into it and mounted the folder with AspeQt, doing a DIR on that virtual drive on the Atari computer shows the ATR file in the folder. I then removed the USB stick and observed AspeQt noticing that the folder Atari is still mounted, doing a DIR on it on the Atari computer however now shows an empty directory of that folder. This is as I expected. AspeQt after mounting a folder always re-reads the contents of the folder when that folder is accessed by the Atari computer, thus it shows an empty directory after the USB stick is removed.

 

I then copied some more ATR files into that Atari folder using my laptop and re-inserted the USB stick to the PC. When I did a DIR on the Atari I can now see the old ATR file as well as new ones I added to the folder with my laptop.

 

Now, I do not know how you have a different experience, maybe an XP machine acts differently then a Win 7 machine, but I have to verify that by repeating my test on my XP PC.

 

 

EDIT: I also tested this with my XP machine and I have the same behavior there. Re-insert the removable media with new files in it and do a DIR from the Atari, new files show-up on the folder. This means I need more info from you to duplicate the problem (if any). What kind of removable media are you using?

Thank you for looking into this. I don't know if it would make any difference but, I don't think my Atari was on when I removed the card. I am using a 2GB SD card in a USB adapter. Maybe it is something strange with my USB/SD adapter? Also at the time, I had only mounted folders on the SD card. Now I have moved some things onto the PC hard drive and mounted a folder on the hard drive as the boot disk. So, this shouldn't be a big deal. Even if the SD card doesn't remount for some reason, I will still have some things to work with from the folder on the PC hard drive.

[atari8warez]

Thank you for looking into this. I don't know if it would make any difference but, I don't think my Atari was on when I removed the card. I am using a 2GB SD card in a USB adapter. Maybe it is something strange with my USB/SD adapter? Also at the time, I had only mounted folders on the SD card. Now I have moved some things onto the PC hard drive and mounted a folder on the hard drive as the boot disk. So, this shouldn't be a big deal. Even if the SD card doesn't remount for some reason, I will still have some things to work with from the folder on the PC hard drive.

 

Whether your Atari was ON or OFF wouldn't make any difference on AspeQt. The fact is AspeQt does not unmount a folder if the removable media is removed. When you re-insert the media with new files on it, your Atari will be able to read the new directory from the folder. As I mentioned before, AspeQt re-reads the directory of the folder every time the folder is accessed from your Atari. This also means you can add more files to your folder using your PC and without actually removing the media, and those files will be visible to your Atari next time it requests a directory list.

Edited December 9, 2013 by atari8warez

[flashjazzcat]

Have posted sample executable and Aspeqt logs on the Sourceforge tracker as requested regarding SDX file execution from imaged folder issue. I have since noted that the Aspeqt build containing my original SDX folder imaging fix does not have this problem and allows running of the sample executable without issue, so I have temporarily reverted to that one until the problem is sorted out. Thanks for the reminder about this.

[atari8warez]

Have posted sample executable....

 

Jon, here's another twist to this odd problem, when I tried loading the file you sent me using SDX X command, the XEX file loads and executes properly from the folder image. When I copy it to an ATR image, then the file also loads without the X command. Do you have any idea why? I also noticed the same XEX file shows two different sizes depending on where it is located. If it is in the Folder image the size shows as 21375 bytes, when it is copied to an ATR it's size is 21268, so there is 107 bytes of difference. Something strange is going on in the code

Edited December 18, 2013 by atari8warez

[phaeron]

The DOS 2 filesystem only stores a sector count in the directory, so when SpartaDOS X generates directory listings for a DOS 2 disk, it fakes the byte size as 125*sectors.The actual file size can't be determined except by reading every sector in the file.

[atari8warez]

The DOS 2 filesystem only stores a sector count in the directory, so when SpartaDOS X generates directory listings for a DOS 2 disk, it fakes the byte size as 125*sectors.The actual file size can't be determined except by reading every sector in the file.

 

of course!, i forgot all about that, thanks Phaeron...

[flashjazzcat]

 

Jon, here's another twist to this odd problem, when I tried loading the file you sent me using SDX X command, the XEX file loads and executes properly from the folder image. When I copy it to an ATR image, then the file also loads without the X command. Do you have any idea why?

 

The executable can be loaded with or without the SDX library present, if that's what you mean. You only need to use "X" if you need the RAM under the cartridge for the RC_GR8.SYS driver's frame buffer.

 

The current folder imaging implementation has a "special case" fix which I didn't put in my original implementation (namely to handle SDX reading the same sector twice during file copy, IIRC), but I'm not sure if that's anything to do with the issue. The simplified implementation I originally came up with works with or without the "X" command.

 

With reference to the above, however, I tried using "X" here and the sample executable did run, so I collated the sector logs for a failed and successful load:

Without "X" (Failed load)

[Disk 2] Read sector 361 (128 bytes).
[Disk 2] Read sector 407 (128 bytes).
[Disk 2] Read sector 433 (128 bytes).
[Disk 2] Read sector 434 (128 bytes).
[Disk 2] Read sector 435 (128 bytes).
[Disk 2] Read sector 436 (128 bytes).
[Disk 2] Read sector 437 (128 bytes).
[Disk 2] Read sector 438 (128 bytes).
[Disk 2] Read sector 439 (128 bytes).
[Disk 2] Read sector 440 (128 bytes).
[Disk 2] Read sector 441 (128 bytes).
[Disk 2] Read sector 442 (128 bytes).
[Disk 2] Read sector 443 (128 bytes).
[Disk 2] Read sector 444 (128 bytes).
[Disk 2] Read sector 445 (128 bytes).
[Disk 2] Read sector 446 (128 bytes).
[Disk 2] Read sector 447 (128 bytes).
[Disk 2] Read sector 448 (128 bytes).
[Disk 2] Read sector 449 (128 bytes).
[Disk 2] Read sector 450 (128 bytes).
[Disk 2] Read sector 451 (128 bytes).
[Disk 2] Read sector 452 (128 bytes).
[Disk 2] Read sector 453 (128 bytes).
[Disk 2] Read sector 454 (128 bytes).
[Disk 2] Read sector 455 (128 bytes).
[Disk 2] Read sector 456 (128 bytes).
[Disk 2] Read sector 457 (128 bytes).
[Disk 2] Read sector 458 (128 bytes).
[Disk 2] Read sector 459 (128 bytes).
[Disk 2] Read sector 460 (128 bytes).
[Disk 2] Read sector 461 (128 bytes).
[Disk 2] Read sector 462 (128 bytes).
[Disk 2] Read sector 463 (128 bytes).
[Disk 2] Read sector 464 (128 bytes).
[Disk 2] Read sector 465 (128 bytes).
[Disk 2] Read sector 466 (128 bytes).
[Disk 2] Read sector 467 (128 bytes).
[Disk 2] Read sector 468 (128 bytes).
[Disk 2] Read sector 469 (128 bytes).
[Disk 2] Read sector 470 (128 bytes).
[Disk 2] Read sector 471 (128 bytes).
[Disk 2] Read sector 472 (128 bytes).
[Disk 2] Read sector 473 (128 bytes).
[Disk 2] Read sector 474 (128 bytes).
[Disk 2] Read sector 475 (128 bytes).
[Disk 2] Read sector 476 (128 bytes).
[Disk 2] Read sector 477 (128 bytes).
[Disk 2] Read sector 478 (128 bytes).
[Disk 2] Read sector 479 (128 bytes).
[Disk 2] Read sector 480 (128 bytes).
[Disk 2] Read sector 481 (128 bytes).
[Disk 2] Read sector 482 (128 bytes).
[Disk 2] Read sector 483 (128 bytes).
[Disk 2] Read sector 484 (128 bytes).
[Disk 2] Read sector 485 (128 bytes).
[Disk 2] Read sector 486 (128 bytes).
[Disk 2] Read sector 487 (128 bytes).
[Disk 2] Read sector 488 (128 bytes).
[Disk 2] Read sector 489 (128 bytes).
[Disk 2] Read sector 490 (128 bytes).
[Disk 2] Read sector 491 (128 bytes).
[Disk 2] Read sector 492 (128 bytes).
[Disk 2] Read sector 493 (128 bytes).
[Disk 2] Read sector 494 (128 bytes).
[Disk 2] Read sector 495 (128 bytes).
[Disk 2] Read sector 496 (128 bytes).
[Disk 2] Read sector 497 (128 bytes).
[Disk 2] Read sector 498 (128 bytes).
[Disk 2] Read sector 499 (128 bytes).
[Disk 2] Read sector 500 (128 bytes).
[Disk 2] Read sector 501 (128 bytes).
[Disk 2] Read sector 502 (128 bytes).
[Disk 2] Read sector 503 (128 bytes).
[Disk 2] Read sector 504 (128 bytes).
[Disk 2] Read sector 505 (128 bytes).
[Disk 2] Read sector 506 (128 bytes).
[Disk 2] Read sector 507 (128 bytes).
[Disk 2] Read sector 508 (128 bytes).
[Disk 2] Read sector 509 (128 bytes).
[Disk 2] Read sector 510 (128 bytes).
[Disk 2] Read sector 511 (128 bytes).
[Disk 2] Read sector 512 (128 bytes).
[Disk 2] Read sector 513 (128 bytes).
[Disk 2] Read sector 514 (128 bytes).
[Disk 2] Read sector 515 (128 bytes).
[Disk 2] Read sector 516 (128 bytes).
[Disk 2] Read sector 517 (128 bytes).
[Disk 2] Read sector 518 (128 bytes).
[Disk 2] Read sector 519 (128 bytes).
[Disk 2] Read sector 520 (128 bytes).
[Disk 2] Read sector 521 (128 bytes).
[Disk 2] Read sector 522 (128 bytes).
[Disk 2] Read sector 523 (128 bytes).
[Disk 2] Read sector 524 (128 bytes).
[Disk 2] Read sector 525 (128 bytes).
[Disk 2] Read sector 526 (128 bytes).
[Disk 2] Read sector 527 (128 bytes).
[Disk 2] Read sector 528 (128 bytes).
[Disk 2] Read sector 529 (128 bytes).
[Disk 2] Read sector 530 (128 bytes).
[Disk 2] Read sector 531 (128 bytes).
[Disk 2] Read sector 532 (128 bytes).
[Disk 2] Read sector 533 (128 bytes).
[Disk 2] Read sector 534 (128 bytes).
[Disk 2] Read sector 535 (128 bytes).
[Disk 2] Read sector 536 (128 bytes).
[Disk 2] Read sector 537 (128 bytes).
[Disk 2] Read sector 538 (128 bytes).
[Disk 2] Read sector 539 (128 bytes).
[Disk 2] Read sector 540 (128 bytes).
[Disk 2] Read sector 541 (128 bytes).
[Disk 2] Read sector 542 (128 bytes).
[Disk 2] Read sector 543 (128 bytes).
[Disk 2] Read sector 544 (128 bytes).
[Disk 2] Read sector 545 (128 bytes).
[Disk 2] Read sector 546 (128 bytes).
[Disk 2] Read sector 547 (128 bytes).
[Disk 2] Read sector 548 (128 bytes).
[Disk 2] Read sector 549 (128 bytes).
[Disk 2] Read sector 550 (128 bytes).
[Disk 2] Read sector 551 (128 bytes).
[Disk 2] Read sector 552 (128 bytes).
[Disk 2] Read sector 553 (128 bytes).
[Disk 2] Read sector 554 (128 bytes).
[Disk 2] Read sector 555 (128 bytes).
[Disk 2] Read sector 556 (128 bytes).
[Disk 2] Read sector 557 (128 bytes).
[Disk 2] Read sector 558 (128 bytes).
[Disk 2] Read sector 559 (128 bytes).
[Disk 2] Read sector 560 (128 bytes).
[Disk 2] Read sector 561 (128 bytes).
[Disk 2] Read sector 562 (128 bytes).
[Disk 2] Read sector 563 (128 bytes).
[Disk 2] Read sector 564 (128 bytes).
[Disk 2] Read sector 565 (128 bytes).
[Disk 2] Read sector 566 (128 bytes).
[Disk 2] Read sector 567 (128 bytes).
[Disk 2] Read sector 568 (128 bytes).
[Disk 2] Read sector 569 (128 bytes).
[Disk 2] Read sector 570 (128 bytes).
[Disk 2] Read sector 571 (128 bytes).
[Disk 2] Read sector 572 (128 bytes).
[Disk 2] Read sector 573 (128 bytes).
[Disk 2] Read sector 574 (128 bytes).
[Disk 2] Read sector 575 (128 bytes).
[Disk 2] Read sector 576 (128 bytes).
[Disk 2] Read sector 577 (128 bytes).
[Disk 2] Read sector 578 (128 bytes).
[Disk 2] Read sector 579 (128 bytes).
[Disk 2] Read sector 580 (128 bytes).
[Disk 2] Read sector 581 (128 bytes).
[Disk 2] Read sector 582 (128 bytes).
[Disk 2] Read sector 407 (128 bytes).
[Disk 2] Read sector 433 (128 bytes).
[Disk 2] Read sector 434 (128 bytes).
[Disk 2] Read sector 435 (128 bytes).
[Disk 2] Read sector 436 (128 bytes).
[Disk 2] Read sector 437 (128 bytes).
[Disk 2] Read sector 438 (128 bytes).
[Disk 2] Read sector 439 (128 bytes).
[Disk 2] Read sector 440 (128 bytes).
[Disk 2] Read sector 441 (128 bytes).
[Disk 2] Read sector 442 (128 bytes).
[Disk 2] Read sector 443 (128 bytes).
[Disk 2] Read sector 444 (128 bytes).
[Disk 2] Read sector 445 (128 bytes).
[Disk 2] Read sector 446 (128 bytes).
[Disk 2] Read sector 447 (128 bytes).
[Disk 2] Read sector 448 (128 bytes).
[Disk 2] Read sector 449 (128 bytes).
[Disk 2] Read sector 450 (128 bytes).
[Disk 2] Read sector 451 (128 bytes).

With "X" (Successful load)

[Disk 2] Read sector 361 (128 bytes).
[Disk 2] Read sector 407 (128 bytes).
[Disk 2] Read sector 433 (128 bytes).
[Disk 2] Read sector 434 (128 bytes).
[Disk 2] Read sector 435 (128 bytes).
[Disk 2] Read sector 436 (128 bytes).
[Disk 2] Read sector 437 (128 bytes).
[Disk 2] Read sector 438 (128 bytes).
[Disk 2] Read sector 439 (128 bytes).
[Disk 2] Read sector 440 (128 bytes).
[Disk 2] Read sector 441 (128 bytes).
[Disk 2] Read sector 442 (128 bytes).
[Disk 2] Read sector 443 (128 bytes).
[Disk 2] Read sector 444 (128 bytes).
[Disk 2] Read sector 445 (128 bytes).
[Disk 2] Read sector 446 (128 bytes).
[Disk 2] Read sector 447 (128 bytes).
[Disk 2] Read sector 448 (128 bytes).
[Disk 2] Read sector 449 (128 bytes).
[Disk 2] Read sector 450 (128 bytes).
[Disk 2] Read sector 451 (128 bytes).
[Disk 2] Read sector 452 (128 bytes).
[Disk 2] Read sector 453 (128 bytes).
[Disk 2] Read sector 454 (128 bytes).
[Disk 2] Read sector 455 (128 bytes).
[Disk 2] Read sector 456 (128 bytes).
[Disk 2] Read sector 457 (128 bytes).
[Disk 2] Read sector 458 (128 bytes).
[Disk 2] Read sector 459 (128 bytes).
[Disk 2] Read sector 460 (128 bytes).
[Disk 2] Read sector 461 (128 bytes).
[Disk 2] Read sector 462 (128 bytes).
[Disk 2] Read sector 463 (128 bytes).
[Disk 2] Read sector 464 (128 bytes).
[Disk 2] Read sector 465 (128 bytes).
[Disk 2] Read sector 466 (128 bytes).
[Disk 2] Read sector 467 (128 bytes).
[Disk 2] Read sector 468 (128 bytes).
[Disk 2] Read sector 469 (128 bytes).
[Disk 2] Read sector 470 (128 bytes).
[Disk 2] Read sector 471 (128 bytes).
[Disk 2] Read sector 472 (128 bytes).
[Disk 2] Read sector 473 (128 bytes).
[Disk 2] Read sector 474 (128 bytes).
[Disk 2] Read sector 475 (128 bytes).
[Disk 2] Read sector 476 (128 bytes).
[Disk 2] Read sector 477 (128 bytes).
[Disk 2] Read sector 478 (128 bytes).
[Disk 2] Read sector 479 (128 bytes).
[Disk 2] Read sector 480 (128 bytes).
[Disk 2] Read sector 481 (128 bytes).
[Disk 2] Read sector 482 (128 bytes).
[Disk 2] Read sector 483 (128 bytes).
[Disk 2] Read sector 484 (128 bytes).
[Disk 2] Read sector 485 (128 bytes).
[Disk 2] Read sector 486 (128 bytes).
[Disk 2] Read sector 487 (128 bytes).
[Disk 2] Read sector 488 (128 bytes).
[Disk 2] Read sector 489 (128 bytes).
[Disk 2] Read sector 490 (128 bytes).
[Disk 2] Read sector 491 (128 bytes).
[Disk 2] Read sector 492 (128 bytes).
[Disk 2] Read sector 493 (128 bytes).
[Disk 2] Read sector 494 (128 bytes).
[Disk 2] Read sector 495 (128 bytes).
[Disk 2] Read sector 496 (128 bytes).
[Disk 2] Read sector 497 (128 bytes).
[Disk 2] Read sector 498 (128 bytes).
[Disk 2] Read sector 499 (128 bytes).
[Disk 2] Read sector 500 (128 bytes).
[Disk 2] Read sector 501 (128 bytes).
[Disk 2] Read sector 502 (128 bytes).
[Disk 2] Read sector 503 (128 bytes).
[Disk 2] Read sector 504 (128 bytes).
[Disk 2] Read sector 505 (128 bytes).
[Disk 2] Read sector 506 (128 bytes).
[Disk 2] Read sector 507 (128 bytes).
[Disk 2] Read sector 508 (128 bytes).
[Disk 2] Read sector 509 (128 bytes).
[Disk 2] Read sector 510 (128 bytes).
[Disk 2] Read sector 511 (128 bytes).
[Disk 2] Read sector 512 (128 bytes).
[Disk 2] Read sector 513 (128 bytes).
[Disk 2] Read sector 514 (128 bytes).
[Disk 2] Read sector 515 (128 bytes).
[Disk 2] Read sector 516 (128 bytes).
[Disk 2] Read sector 517 (128 bytes).
[Disk 2] Read sector 518 (128 bytes).
[Disk 2] Read sector 519 (128 bytes).
[Disk 2] Read sector 520 (128 bytes).
[Disk 2] Read sector 521 (128 bytes).
[Disk 2] Read sector 522 (128 bytes).
[Disk 2] Read sector 523 (128 bytes).
[Disk 2] Read sector 524 (128 bytes).
[Disk 2] Read sector 525 (128 bytes).
[Disk 2] Read sector 526 (128 bytes).
[Disk 2] Read sector 527 (128 bytes).
[Disk 2] Read sector 528 (128 bytes).
[Disk 2] Read sector 529 (128 bytes).
[Disk 2] Read sector 530 (128 bytes).
[Disk 2] Read sector 531 (128 bytes).
[Disk 2] Read sector 532 (128 bytes).
[Disk 2] Read sector 533 (128 bytes).
[Disk 2] Read sector 534 (128 bytes).
[Disk 2] Read sector 535 (128 bytes).
[Disk 2] Read sector 536 (128 bytes).
[Disk 2] Read sector 537 (128 bytes).
[Disk 2] Read sector 538 (128 bytes).
[Disk 2] Read sector 539 (128 bytes).
[Disk 2] Read sector 540 (128 bytes).
[Disk 2] Read sector 541 (128 bytes).
[Disk 2] Read sector 542 (128 bytes).
[Disk 2] Read sector 543 (128 bytes).
[Disk 2] Read sector 544 (128 bytes).
[Disk 2] Read sector 545 (128 bytes).
[Disk 2] Read sector 546 (128 bytes).
[Disk 2] Read sector 547 (128 bytes).
[Disk 2] Read sector 548 (128 bytes).
[Disk 2] Read sector 549 (128 bytes).
[Disk 2] Read sector 550 (128 bytes).
[Disk 2] Read sector 551 (128 bytes).
[Disk 2] Read sector 552 (128 bytes).
[Disk 2] Read sector 553 (128 bytes).
[Disk 2] Read sector 554 (128 bytes).
[Disk 2] Read sector 555 (128 bytes).
[Disk 2] Read sector 556 (128 bytes).
[Disk 2] Read sector 557 (128 bytes).
[Disk 2] Read sector 558 (128 bytes).
[Disk 2] Read sector 559 (128 bytes).
[Disk 2] Read sector 560 (128 bytes).
[Disk 2] Read sector 561 (128 bytes).
[Disk 2] Read sector 562 (128 bytes).
[Disk 2] Read sector 563 (128 bytes).
[Disk 2] Read sector 564 (128 bytes).
[Disk 2] Read sector 565 (128 bytes).
[Disk 2] Read sector 566 (128 bytes).
[Disk 2] Read sector 567 (128 bytes).
[Disk 2] Read sector 568 (128 bytes).
[Disk 2] Read sector 569 (128 bytes).
[Disk 2] Read sector 570 (128 bytes).
[Disk 2] Read sector 571 (128 bytes).
[Disk 2] Read sector 572 (128 bytes).
[Disk 2] Read sector 573 (128 bytes).
[Disk 2] Read sector 574 (128 bytes).
[Disk 2] Read sector 575 (128 bytes).
[Disk 2] Read sector 576 (128 bytes).
[Disk 2] Read sector 577 (128 bytes).
[Disk 2] Read sector 578 (128 bytes).
[Disk 2] Read sector 579 (128 bytes).
[Disk 2] Read sector 580 (128 bytes).
[Disk 2] Read sector 581 (128 bytes).
[Disk 2] Read sector 582 (128 bytes).
[Disk 2] Read sector 583 (128 bytes).
[Disk 2] Read sector 584 (128 bytes).
[Disk 2] Read sector 585 (128 bytes).
[Disk 2] Read sector 586 (128 bytes).
[Disk 2] Read sector 587 (128 bytes).
[Disk 2] Read sector 588 (128 bytes).
[Disk 2] Read sector 589 (128 bytes).
[Disk 2] Read sector 590 (128 bytes).
[Disk 2] Read sector 591 (128 bytes).
[Disk 2] Read sector 592 (128 bytes).
[Disk 2] Read sector 593 (128 bytes).
[Disk 2] Read sector 594 (128 bytes).
[Disk 2] Read sector 595 (128 bytes).
[Disk 2] Read sector 596 (128 bytes).
[Disk 2] Read sector 597 (128 bytes).
[Disk 2] Read sector 598 (128 bytes).
[Disk 2] Read sector 599 (128 bytes).
[Disk 2] Read sector 600 (128 bytes).
[Disk 2] Read sector 601 (128 bytes).
[Disk 2] Read sector 602 (128 bytes).
[Disk 2] Get status.

The failed load (without "X") gets to sector 582 and then loops back to the first sector of the file for some reason, while the successful load runs right through to 602, so I can't see this being anything to do with reallocated sector numbers on the server side. The only difference I can think of regarding use of the "X" command in SDX is that the load will not be buffered. When you just type the program name (without "X"), the relocatable loader is used, which inspects the binary heads and handles relocatable segments appropriately. Standard $FFFF headers are treated appropriately, of course. "X" only handles standard binaries and nothing else, and I seem to recall the original SDX 4.18 documentation mentioning that the mini-buffers aren't used when the library is disabled.

 

Perhaps Drac030 can shed some light... but having said that, the version I wrote works in both cases, so it seems a little pointless trying to figure out what SDX is doing. I didn't feel it was important to support files longer than eighty-odd KB in what is ostensibly a 90KB simulated disk, and therefore data sector numbers aren't typically reused at all (the data sectors are allocated from the start of the volume, merely skipping the directory sectors). Thus the sector number corresponds directly to the file offset (sector_number * 125), so if SDX reads the same sector twice, it gets the same data and the cache remains valid. About the only thing I can suggest is double-checking that "double sector read" code in your implementation. I can't see anything else suspect.

Edited December 18, 2013 by flashjazzcat

[atari8warez]

Thank you for the insight, I tend to think that the issue is with the buffering given the fact that the file loads correctly when the SDX library is not used (no buffering). I will re-check the code I implemented to handle double sector read. Yes I can take and implement your code to fix the problem but I want to understand what is exactly happening.

Edited December 18, 2013 by atari8warez