Spartados X and FatFS... Issues

[Jeffrey Worley]

I have an 800xl with U1MB and Side2 cart with a CF adapter and a sandisk 16gig card.  The issues are the same with other cards, smaller or larger.  I have SDX 4.49c  loading with the FatFS .86L drivers.  Either from Config.sys or from the command line, the issue is the same.  On a machine without the u1mb (256k rambo xl), the issue is the same.

 

My U1MB and Side2 are running the most current firmware as of the date of this post.

 

I can copy a file, in this case Gauntletak (d5:g\gauntl_1.xex) to the O: ramdisk on the U1mb or the ramdisk on the stock xl with the rambo in it.  The transfer works perfectly.  I can then copy that file on the ramdisk to any drive on the system without fault.

 

I cannot copy this file from the fat16 drive (d5:g>gautl_1.xex) to any other disk on the Side2 cart, be it a 512byte or 256byte formatted disk.  It reads the full file (it is only 23k), and then fails at write with an Error 144.  Why?  I can copy to the ramdisk, then copy to A:, or from any Atari formatted disk to A: or any other atari disk, but with the source as a fat disk, it barfs as though the destination disk were corrupt or broken.  The error is soft in that it doesn't corrupt memory or destabilize the system or anything I can detect of that sort.

 

I'd really like to be able to copy from fat16 partitions using Copy /rs d5:*.* a:>  (for example), but this error kills the process, of course, on the first file, with Write protected or bad sector.

 

Have I discovered an actual bug?  Am I just stupid?  

 

My fatfs parameters for d5 (E:), via CHKFAT are:

 

Magic byte $EB

EOR mask $00

Root entries 1024

Bytes/sector 512

Sector count 3831808

Sector addr. 24-bit

No. of fats 2

Cluster no. 59862

Fat version Fat16

 

The partitions were created on Ubuntu Linux v 19.04 using Gparted.

 

Best,

 

Jeff

 

 

 

Edited September 18, 2019 by Technoid Mutant
Greater detail

[_The Doctor__]

we need to know what you are copying to, not from in this instance...

you can read fatfs using that driver but more than likely can't write to fatfs with it.. so from fatfs to APT or any other may work but not to fatfs....

Edited September 19, 2019 by _The Doctor__

[Jeffrey Worley]

1 hour ago, _The Doctor__ said:

we need to know what you are copying to, not from in this instance...

you can read fatfs using that driver but more than likely can't write to fatfs with it.. so from fatfs to APT or any other may work but not to fatfs....

I'm aware that the FatFS functionality is Read-Only.  The destination drives are all spartados formatted disks, either ramdisks or, where the failure occurs, disks hosted on the SD card on the Side2 cart.

 

I'm copying to a spartados formatted hard disk partition mounted as a:  It is a 32mb partition.  I also can't copy to a 16mb partition on the same card, formatted with 65534 256-byte sectors.  I CAN copy to my G: drive, which is a 16mb spartados partition hosted on my pc by AtariSIO (SioUSB).  I can copy to my ramdisks, whether that is the one on the U1MB, or a rambo 256k I have that has no other upgrades in it. 

[_The Doctor__]

config.sys please

and whatever .bat your starting with

 

Edited September 19, 2019 by _The Doctor__

[Jeffrey Worley]

26 minutes ago, _The Doctor__ said:

config.sys please

and whatever .bat your starting with

 

Config.sys:

 

Use Banked

Device Sparta

Device Sio

Device Ataridos

Device D1:dos>fatfs

Device ramdisk

device ultime

device quicked

device side

 

Autoexec.bat

 

key on

poke 82,0

prompt $L$P\

td on

set manpath=car:;a:\dos\man

set path=a:\dos;car:

cls

 

It doesn't matter though.  If I launch the Fatfs.sys from the command line the problem is the same.  If I switch machines to a non-U1mb machine with a 256k ramdisk and use the side2 cart by itself, the problem is the same.

 

Best,

 

Jeff

Edited September 19, 2019 by Technoid Mutant
typo

[_The Doctor__]

I'd been using fatfs with the AVG cart in SIDE mode for quite a while until the SD card blew. So I'm going to work towards that end with your rambo config. Pictures of this were posted with a double tower of mixed super carts etc... I do know I had to put the fatfs and side drivers early in the config though... probably so I could snag configs from the proper partitions though. I put the drivers in the SDX imager so they'd be available and not rely on it coming from a partition or floppy...

I'll play with this tonight or tomorrow before 3pm

 

make sure to use full path to get started from the fatfs drives though... the driver doesn't always like searching the defaults on a fatfs drive. Make sure volume names are on the drives if possible as well. It may not show in the directories but depending on what revision of this or that it helps...

 

Edited September 19, 2019 by _The Doctor__

[flashjazzcat]

10 hours ago, Technoid Mutant said:

Have I discovered an actual bug?

I just tested this, since my 'Has he discovered a bug' radar went crazy.  Using U1MB/SIDE, copying a 40K file from a FAT16 volume (drive I:, mounted as an external APT volume) to an SDFS formatted APT volume (drive C:) worked without errors. So: make sure you don't have the write-protect enabled on the HDD (I'm sure you don't), and try copying a shorter file (only a few bytes). If the shorter copy works, it would suggest you're getting write errors which are scrambling the destination file's sector map and resulting in out-of-bounds sector IO requests.

 

Also take note of whether the error appears instantly when the destination file is first written to, or whether problems occur part-way through the write. 

8 hours ago, Technoid Mutant said:

Config.sys:

 

Use Banked

Device Sparta

Device Sio

Device Ataridos

Device D1:dos>fatfs

Device ramdisk

device ultime

device quicked

device side

Assuming you're using the HDD in U1MB PBI mode (which you must be if you're hosting CONFIG.SYS on the HDD itself), DEVICE SIDE should not be there. SIDE.SYS is intended for use when U1MB is not present. When the PBI HDD is enabled in the U1MB BIOS, HDD communications essentially happen at the OS level (SIOV). But when no PBI BIOS is available (i.e. when you boot SDX off a stand-alone SIDE cart in a stock machine), SIDE.SYS patches the SDX SIO driver so that it can communicate with the hard disk. You don't need to use both methods at once, which is why there's no DEVICE SIDE entry in CONFIG.SYS on the CAR: device of the U1MB SDX ROM.

[Jeffrey Worley]

15 minutes ago, flashjazzcat said:

I just tested this, since my 'Has he discovered a bug' radar went crazy.  Using U1MB/SIDE, copying a 40K file from a FAT16 volume (drive I:, mounted as an external APT volume) to an SDFS formatted APT volume (drive C:) worked without errors. So: make sure you don't have the write-protect enabled on the HDD (I'm sure you don't), and try copying a shorter file (only a few bytes). If the shorter copy works, it would suggest you're getting write errors which are scrambling the destination file's sector map and resulting in out-of-bounds sector IO requests.

 

Also take note of whether the error appears instantly when the destination file is first written to, or whether problems occur part-way through the write. 

Assuming you're using the HDD in U1MB PBI mode (which you must be if you're hosting CONFIG.SYS on the HDD itself), DEVICE SIDE should not be there. SIDE.SYS is intended for use when U1MB is not present. When the PBI HDD is enabled in the U1MB BIOS, HDD communications essentially happen at the OS level (SIOV). But when no PBI BIOS is available (i.e. when you boot SDX off a stand-alone SIDE cart in a stock machine), SIDE.SYS patches the SDX SIO driver so that it can communicate with the hard disk. You don't need to use both methods at once, which is why there's no DEVICE SIDE entry in CONFIG.SYS on the CAR: device of the U1MB SDX ROM.

Yeah, it just fails to load on boot with an error 170.  I put it in there for a test some time ago on this machine and neglected to change it back.

 

The error occurs instantly on beginning the write process.  It doesn't even manage to create a directory entry.  The read process (which is through the FatFS driver).  The write process only fails to write to Side2-hosted Atari partitions, writes to ramdisk or to sio disks go just fine, even the recursive copy I noted above works fine when the destination is the U1MB ramdisk, the Rambo ramdisk, or the Sio disk.  This is a strange glitch.

 

Best,

 

Jeff

[Roydea6]

The newest and latest fatfs driver should return this information FATFS v.0.87L this driver is 3911 bytes.

[Jeffrey Worley]

3 hours ago, Technoid Mutant said:

Yeah, it just fails to load on boot with an error 170.  I put it in there for a test some time ago on this machine and neglected to change it back.

 

The error occurs instantly on beginning the write process.  It doesn't even manage to create a directory entry.  The read process (which is through the FatFS driver).  The write process only fails to write to Side2-hosted Atari partitions, writes to ramdisk or to sio disks go just fine, even the recursive copy I noted above works fine when the destination is the U1MB ramdisk, the Rambo ramdisk, or the Sio disk.  This is a strange glitch.

 

Best,

 

Jeff

I left a sentence unfinished.  The read process (which is through the FatFS driver) completes, then the system goes to the Atari partition and errors out immediately with an error 144, not managing and writes at all, to directory space or otherwise.

 

[flashjazzcat]

11 minutes ago, Technoid Mutant said:

The read process (which is through the FatFS driver) completes, then the system goes to the Atari partition and errors out immediately with an error 144, not managing and writes at all, to directory space or otherwise.

If you can ZIP up a raw binary dump of the entire card (starting at physical sector 0, not just a copy of logical partitions) and link it somewhere, I'll take a look at it here.

 

[Jeffrey Worley]

12 hours ago, rdea6 said:

The newest and latest fatfs driver should return this information FATFS v.0.87L this driver is 3911 bytes.

Hmm.  My fatfs gives 3893 bytes and a greation date of 17-02-16.  could this be my issue?

I'm gonna d/l the latest from FJC, but I thought I'd done so already.  I just d/led the latest version from the SDX site http://sdx.atari8.info/index.php?show=en_download_special and it has the same version of .86L I'm running now.  3893 byes. and a creation date of February 17, 2016.

 

Wierd Glitch.mkv

Edited September 19, 2019 by Technoid Mutant
Update

[_The Doctor__]

http://sdx.atari8.info/index.php?show=en_download_beta

get the toolkit from here and then unarc....

I think that's where I got fatfs from but don't really remember... the beta here is already a revision behind but it should have it

[Jeffrey Worley]

11 hours ago, flashjazzcat said:

If you can ZIP up a raw binary dump of the entire card (starting at physical sector 0, not just a copy of logical partitions) and link it somewhere, I'll take a look at it here.

 

I did just that.  I did the following to the 16 gig Sandisk micro sd card I removed from the Side2 and plugged into my PC running Kubuntu Linux 19.04:

 

sudo dd if=/dev/mmcblk0 of=/home/technoid/ataridisk.dd bs=512 status=progress
 

Then I zipped the resulting file and uploaded it to my google drive.  It is 2.9 gig because it has a buncha files in two fat partitions, but it was easier this way.  Unzip the file and then:

 

sudo dd if=/path/ataridisk.dd of=/dev/whateverdeviceisdestination bs=512 status=progress

 

That will spit out the raw sectors to your destination card.  You can also use a utility under windows to spit out a raw file to a card/usb stick.  Rufus comes to mind.

 

Here's the google drive link to the zipped ataridisk.dd file, called Ataridisk-dd.zip

 

https://drive.google.com/open?id=11MJOyFQnlgWC_38PzsRoR8TBSaEruFop

 

Best,

 

Jeff

[Kyle22]

That Error - 144 is exactly why I am running 4.47 instead of 4.49x. Same thing on Incognito. I believe it involved copying between different type drives, IIRC.

 

Edited September 20, 2019 by Kyle22
add a word

[Jeffrey Worley]

2 minutes ago, Kyle22 said:

That Error - 144 is exactly why I am running 4.47 instead of 4.49x. Same thing on Incognito. I believe it involved copying between different type drives, IIRC.

 

Oh wow.  Ok.  That's worth knowing.  Someone d/led my movie, bore-ass though it must be.  I worked pretty hard to make the thing.  The video is horrible because my video capture card is pretty horrible.  It works though and it is plenty watchable.  So I might try to downgrade to 4.47 and see what gives.  Thanks for the info!

 

Best,

 

Jeff

[Jeffrey Worley]

1 hour ago, _The Doctor__ said:

http://sdx.atari8.info/index.php?show=en_download_beta

get the toolkit from here and then unarc....

I think that's where I got fatfs from but don't really remember... the beta here is already a revision behind but it should have it

I did just that, and the drivers inside the fatfs.arc in that toolkit are the same version as the ones I have already, same byte count, same revision date.  Sigh.

 

Oh, and no, I just tried the driver from that set.  It reports 0.86L and gives the same error 144 under the same circumstances.  Sigh.

 

Jeff

Edited September 20, 2019 by Technoid Mutant
update

[Kyle22]

Let us know if it works.

 

[Kyle22]

Please note that if you have an 802 or an 816 with NO upper RAM >$FFFF, SDX 4.48 will freeze and not be usable at all. You'll need to boot from SIO, and it's a real mess to fix it.

 

[Jeffrey Worley]

3 minutes ago, Kyle22 said:

Please note that if you have an 802 or an 816 with NO upper RAM >$FFFF, SDX 4.48 will freeze and not be usable at all. You'll need to boot from SIO, and it's a real mess to fix it.

 

Stock cpu.  U1MB, but even without the U1MB (I have a stock xl in the closet), it does the same thing.  My video shows that on the U1MB with the U1MB PBI disabled and the Side2 running with the Side driver.  Same same.

 

Best,

 

Jeff

[_The Doctor__]

15 hours ago, rdea6 said:

The newest and latest fatfs driver should return this information FATFS v.0.87L this driver is 3911 bytes.

Can you attach .87L for him I've had no luck getting this SD card to show any signs of life... there used to be a utility to recover SD card files and then you could us the tool to fix the card... but I can't find that either... it was free, google keeps sending me to buy this pay this it might work type stuff...

[Roydea6]

 

Not positive where I got it but most probable from toolkit for SpartaDos 448 X 

fatfs.arc

Edited September 20, 2019 by rdea6

[flashjazzcat]

11 hours ago, Technoid Mutant said:

Here's the google drive link to the zipped ataridisk.dd file, called Ataridisk-dd.zip

 

https://drive.google.com/open?id=11MJOyFQnlgWC_38PzsRoR8TBSaEruFop

Thanks for that. I've set it up in Altirra and the issue is entirely reproducible, so it's not a hardware glitch. The error code appears to originate (following a sector read operation) from the SDX SIO driver itself, which is odd since the read operation on D1: should have been passed directly to the PBI or SIDE driver. But for some reason SIO driver code (I assume; it could also be the FAT driver but it would be unusual for a filesystem driver to return error $90) in the DOS extended bank is returning this error:

 

 

I'm using SDX 4.49c, BTW. Without disassembling and laboriously tracing the entire process, however, it's going to be difficult to track the issue down.

[flashjazzcat]

More interesting yet: tried the same HDD image with IDE Plus 2.0 in emulation using SDX 4.47 and the same FATFS.SYS (0.86L) and I can't even get a directory of E: (Unknown file system). If that wasn't strange enough, booting SDX 4.49c from the U1MB instead of the IDE Plus 2.0 (but still running the hard disk off the IDE+), I get the exact same error and can't even get a directory of E:.

 

I think it's going to turn out to be something funny about the FAT volume on your disk image. I tested my own VHD here again and even remounted the SDFS partition on drive A: and copied some files across from the FAT (drive I:) and there was no problem at all.

 

 

Edited September 20, 2019 by flashjazzcat

[Jeffrey Worley]

1 hour ago, flashjazzcat said:

More interesting yet: tried the same HDD image with IDE Plus 2.0 in emulation using SDX 4.47 and the same FATFS.SYS (0.86L) and I can't even get a directory of E: (Unknown file system). If that wasn't strange enough, booting SDX 4.49c from the U1MB instead of the IDE Plus 2.0 (but still running the hard disk off the IDE+), I get the exact same error and can't even get a directory of E:.

 

I think it's going to turn out to be something funny about the FAT volume on your disk image. I tested my own VHD here again and even remounted the SDFS partition on drive A: and copied some files across from the FAT (drive I:) and there was no problem at all.

 

 

I'll make new partitions and see what gives.  Thanks for the diags!

 

An aside (pardon the pun),, but why is it that the side loader program can't read sdfs or atarifs partitions, read INTO them as it can with fat and fat32.  It seems strange it should be so.  It seema to me that being able to launch an executable or mount an atr/dcm/atx from an sdfs native disk would be the first feature, not last.  Also, the swap mechanisms are fragmented and clunky.  They WORK.  I'm just offering constructive criticism.  The black box menu is a good guide imho.

 

I think since we use pc's so much, the native Atari aspect of these devices and associate warez loses emphasis.