Spartados X and FatFS... Issues

[Jeffrey Worley]

1 minute ago, flashjazzcat said:

See my previous post. The DMA setting concerns high speed SIO failures. Disabling the screen allowed the SDX SIO driver to run fast enough to keep pace with low divisors. It has nothing whatsoever to do with the DUNUSE issue concerning FATFS v.0.86L.

What blows my mind is how doggone FAST the thing is.  Even with the screen on you get 65k@sec, which is more than twice the speed of my black box with DMA OFF!, even with that monster 1gig drive I had in the early 90's.  With DMA off, the Side2 pulls 98k@sec.  This is just about as fast as the hardware will go man.  I LOVE the IO noise.  When I move the Side2 to a machine that doesn't have the U1MB, which is fairly often, I really miss the sound.  Any way to stick that in the cartridge by itself?

 

Best,

 

Jeff

[flashjazzcat]

15 minutes ago, Technoid Mutant said:

Even with the screen on you get 65k@sec, which is more than twice the speed of my black box with DMA OFF!

Yes: I certainly don't mean to imply that HDD transfers won't go faster with the screen off, but HDD IO is not subject to the tight timing constraints of serial IO. As for the speed increase: being able to use all of a 512 byte logical sector is a big advantage over older IDE or SCSI host adapters. Very often, the older HDDs would leave half of each 512 byte sector completely unused rather than packing a pair of 256 byte sectors into one physical sector. This necessitated two full 512 byte sector transfers just to shift the same amount of data SDX can now transmit with a single sector transfer. U1MB/SIDE and IDE Plus pad 512 byte sectors when dealing with 128 and 256 byte logical sectors, so they may provide a fairer comparison with devices like the BlackBox. There is some loop unrolling as well which helps edge the speeds up a little, too.

15 minutes ago, Technoid Mutant said:

With DMA off, the Side2 pulls 98k@sec.

The loader has very little overhead and there's commonly no display active when loading an executable. You may observe Yoomp! loading in around one second flat.

15 minutes ago, Technoid Mutant said:

I LOVE the IO noise.  When I move the Side2 to a machine that doesn't have the U1MB, which is fairly often, I really miss the sound.  Any way to stick that in the cartridge by itself?

It is already there. Edit CONFIG.SYS to place the /N switch after 'DEVICE SIDE'. You will have to use the SDX Imaging tool to accomplish this on the CAR: device, of course. But you can test the feature by booting SDX from the SIDE cart with SHIFT held down (this prevents the SIDE driver from loading), and then manually loading the driver by typing:

 

SIDE.SYS /N

 

Edited October 6, 2019 by flashjazzcat

[Jeffrey Worley]

1 minute ago, flashjazzcat said:

Yes: I certainly don't mean to imply that HDD transfers as well as SIO transfers won't go faster with the screen off, but HDD IO is not subject to the tight timing constraints of serial IO. As for the speed increase: being able to use all of a 512 byte logical sector is a big advantage over older IDE or SCSI host adapters. Very often, the older HDDs would leave half of each 512 byte sector completely unused rather than packing a pair of 256 byte sectors into one physical sector. This necessitated two full 512 byte sector transfers just to shift the same amount of data SDX can now transmit with a single sector transfer. U1MB/SIDE and IDE Plus pad 512 byte sectors when dealing with 128 and 256 byte logical sectors, so they may provide a fairer comparison with devices like the BlackBox. There is some loop unrolling as well which helps edge the speeds up a little, too.

The loader has very little overhead and there's commonly no display active when loading an executable. You may observe Yoomp! loading in around one second flat.

It is already there. Edit CONFIG.SYS to place the /N switch after 'DEVICE SIDE'. You will have to use the SDX Imaging tool to accomplish this on the CAR: device, of course. But you can test the feature by booting SDX from the SIDE cart with SHIFT held down (this prevents the SIDE driver from loading), and then manually loading the driver by typing:

 

SIDE.SYS /N

 

Oh wow, THANK YOU!  That is just way cool man.

[Kyle22]

On 10/5/2019 at 4:56 AM, flashjazzcat said:

BTW: You've been asked twice for details on how to reproduce the issue without FATFS and have chosen to ignore the question.

I just tried a large copy operation and got this (no FATFS involved, this was PCLINK). Relevant?

I'm going to need to find a drive that has a FAT partition.

 

Those files are around 620K each.

 

Edited October 6, 2019 by Kyle22
more info.

[flashjazzcat]

Well, that's a CIO error so is not generated by the PBI BIOS. Looks like some oddness with PCLINK.SYS. That's a rather old SDX revision. Perhaps best to try SDX 4.49c, the latest PCLINK.SYS, along with FATFS v.0.87L.

 

The only kernel function not implemented in PCLINK.SYS is setboot, so I have no idea what's causing this.

[Roydea6]

38 minutes ago, Kyle22 said:

Those files are around 620K each.

Kyle22,

Have you tried to use on command line copy /r c:pro  pclk: ?

When I have problems and stalling on pclink.sys copies I usually try this to work with problem files.

or CD PRO>BASES> and then copy /n *.dat pclk:pro>bases>

 

 

[Kyle22]

13 minutes ago, rdea6 said:

Kyle22,

Have you tried to use on command line copy /r c:pro  pclk: ?

When I have problems and stalling on pclink.sys copies I usually try this to work with problem files.

or CD PRO>BASES> and then copy /n *.dat pclk:pro>bases>

 

 

 I did

CD PRO>BASES> and then copy /n *.dat pclk:pro>bases>

 

and it worked for some reason.

 

This is different from the error - 144 issue, I think. I'm going to try 4.49c and 4.49d again and compare results.

 

[Jeffrey Worley]

2 hours ago, Kyle22 said:

I just tried a large copy operation and got this (no FATFS involved, this was PCLINK). Relevant?

I'm going to need to find a drive that has a FAT partition.

 

Those files are around 620K each.

 

That looks like a write to a fatfs partition would look.  The error says no write function in handler (operation not supported).

 

[Kyle22]

10 minutes ago, Technoid Mutant said:

The error says no write function in handler (operation not supported). 

  

Function not implemented, but it WAS until it wasn't. There were NO errors on the RespeQt side

[Jeffrey Worley]

59 minutes ago, Kyle22 said:

Function not implemented, but it WAS until it wasn't. There were NO errors on the RespeQt side

Yeah, I noticed a whole lotta data got writ before it bombed, so there's some boundary being crossed, some bit not getting set or something.  Now I've only run RespeQt to try it, on Linux, so the Windows version may have support I'm not aware of, but on my system the directory mount option only works for AFS, no subdirectory support, and the number of files and the file size are limited according to the Atari 2.5 floppy system.  So there may be something in that that's causing an issue?  File exceeding a certain size?  Is the underline a legal char in afs for a filename?  could the filesize be at issue?

 

Best,

 

Jeff

[_The Doctor__]

another pclink issue is it prefers folders not roots...

easy to reproduce...

pick a network drive with an assigned drive letter and mount it in a slot under respeqt...

now select that drive and get a directory... works to as best repeqt will allow...

now select that drive as a pcl drive... watch it fail...

 

so take that same slot and pick the same network drive letter and pick a folder...

now access it as a pcl drive and it will work... but you can not reach the root drive...

 

I am using slightly older respeqt revision, I am not certain it has been fixed... the last fellow working on it got chased away and I don't think anyone else has taken over from the feller.