Incognito CF partition issues.. out of ideas. Help Please!

[Bikerbob]

That is obvious, but as I understand, Bikerbob wants to edit the default CAR:CONFIG.SYS in this manner. And he has Incognito with switchable RAM size.

 

Generally I would prefer if people did not fiddle so much with the default CONFIG files. The default one's purpose is just to save your ... situation when something goes wrong. And this file is usually optimal for the given build. The customized CONFIG files should rather be loaded from the disk whenever possible. IMHO keeping them there is also much more convenient, because such a file may be edited in a second without reflashing the entire ROM.

 

OK Drac, I am good with leaving it alone.. so then I need to write my own config.sys on my boot drive. BUT I cannot call fatfs.sys from the config... so I need to set up a parm that sets the path first in the config?? then I could just type DEVICE: fatfs.sys and it will load it?

[drac030]

Say you have FATFS.SYS on drive C: (or D3) in subdirectory SYS located in the main directory. And this is also your boot drive.

 

So:

 

1) create your custom CONFIG.SYS file in the main dir of that drive. You may simply copy the default config using

 

TYPE CAR:CONFIG.SYS >>C:>CONFIG.SYS

 

and then edit it with ED

 

2) at the end add this line:

 

DEVICE C:>SYS>FATFS

 

3) save the file, exit to CP, reboot

 

That should be all.

Edited July 31, 2016 by drac030

[Bikerbob]

The logging time depends on the FAT size, and the FAT size depends on the total cluster count. Making a cluster 2x bigger cuts the FAT size in half, and so the logging time also is decreased proportionally.

 

So on the same 32 MB partition a 4k cluster makes FAT 8 times smaller. So you would wait 4 seconds for logging the drive, not half a minute.

 

BTW. splitting a 32 MB FAT disk into ~65000 clusters is probably the worst possible idea (unless someone has ~60000 really short files to save there).

 

Generally: keep the cluster count 32767 or smaller, and to cover larger media rather increase the cluster size. 8 or even 16k per cluster is nothing scary, and this allows the partition to be reasonably large keeping the FATs reasonably small at the same time.

 

I have spent 2 days now trying to find something on windows 7 that will allow me to make a 2gb primary FAT partition on a 8gb cf card with a 4K cluster size.. CANT FIND ANY.. Largest cluster size the one utility would allow me was 64K.. MOST dont even give an option.. DEFAULT only. I assume they are trying to be helpful.. seeing the size of the partition and not wanting to waist space they dont allow such large clusters.

 

Any ideas??

[drac030]

If you want 2 GB, you have to make clusters larger than 4k. The max. capacity with the 4k clusters is 256 MB (but when you want 256 MB, better use 8k clusters)..

Edited July 31, 2016 by drac030

[Bikerbob]

Say you have FATFS.SYS on drive C: (or D3) in subdirectory SYS located in the main directory. And this is also your boot drive.

 

So:

 

1) create your custom CONFIG.SYS file in the main dir of that drive. You may simply copy the default config using

 

TYPE CAR:CONFIG.SYS >>C:>CONFIG.SYS

 

and then edit it with ED

 

2) at the end add this line:

 

DEVICE C:>SYS>FATFS

 

3) save the file, exit to CP, reboot

 

That should be all.

 

Ok, so dont bother with setting a path.. just use the full path.. the syntax > where in the manual is that spelt out? I would have thought the \ used? Thanks for the help btw.

 

I love the screen accelerator and the keyboard buffer.. when using cli.. the keyboard buffer is very helpful, especially on keyboards where clicks sometimes get missed.. SO I want to add those into my config.sys as well.

 

James

[Bikerbob]

If you want 2 GB, you have to make clusters larger than 4k. The max. capacity with the 4k clusters is 256 MB (but when you want 256 MB, better use 8k clusters)..

 

OK.. great to say.. what are you using to do it?? nothing I can find in windows will allow me complete custom control over the partition parms.

 

OK, maybe I am getting ahead of myself here.. Would I want a 2gb fat16?? if it is only read at the moment.. and I have a sio2pc.. if I can get the PCLINK setup.. maybe I am just better to go that route.. and not even bother with this partition?

 

James

 

[edit]

 

Sectors per Cluster: 128 (65536 bytes)

Number of Fats: 2

Reserved Sectors: 32

Sectors per FAT: 139

Root Entries Limit: 512

This is the largest I can set.. that I can find.

Edited July 31, 2016 by Bikerbob

[drac030]

So just leave it to the formatting tool and do not bother. 2 GB with 64k cluster is okay anyway (32767 clusters * 64k = 2 GB).

 

I have formatted my FAT partition under Unix, but my partition is smaller (512 MB) so there were more possibilities in tuning the parameters.

 

'>' is just the traditional SpartaDOS path separator. SpartaDOS X also recognizes '\'. '>>' is the I/O redirection operator.

 

The partition is read only, but if you have it on a CF card you can insert into your PC, then it might prove more convenient than the (serial) PCLINK in copying larger portions of data from PC to the Atari HDD.

Edited July 31, 2016 by drac030

[Bikerbob]

It seems that FATFS.SYS got mangled somewhere along the way, since SDX is attempting to load it, but discovering it is not a readable binary executable.

This was me trying to use the mirrored APE to transfer the files, the issue I am guessing is that APE does not save the properties of the file.

 

Forget writing to mirrored folders using APE with SDX. Doesn't work. Use RespeQt and set up PCLink if you want to write to mirrored folders (see SDX toolkit disk, SDX manual, and RespeQt topic).

 

Alternatively, use Altirra's Disk Explorer to get FATFS.SYS out of the archive on the toolkit and drag it right onto the desktop.

Great suggestion about Altirra - that is something I will remember for future.

 

I would love to get PCLink setup.. but I have yet.. through following the RespeQt forum and the PCLink support to understand what version HAS support? or how I get it to work. Sigh.

 

My goal with APE and hopefully PCLINK was to be able to use PROSYSTEM and 10502pc to transfer all of my disks to the HD(CF card) and or change and make large directories by name.. or type of game etc..

 

Finally - why do I not use the PBI.sys?? is there something in the system already done that I dont need that driver? and why if SDX has the PCL: driver.. can we not use it on that Fat16 partition?

 

James

 

Edited July 31, 2016 by Bikerbob

[flashjazzcat]

R3 of RespeQt has PCLink support, and that's the build you'll get from the main download page. I have provided a precis of the setup procedure for you in your thread in the RespeQt sub-forum.

 

To be honest I'm not 100 per cent certain what PBI.SYS does. It appears to be some kind of wrapper around calls to the math pack overlay, but perhaps Konrad can enlighten us further.

 

I'm not sure I understand the point regarding PCLink and FAT16. PCLink is a protocol for communication with an "intelligent" server at the PC end. The computer asks the PCLink server to open a file for write (via a command), the server opens it, then the computer sends a frame of data, which the server writes to the open file, etc.

Edited July 31, 2016 by flashjazzcat

[drac030]

PBI.SYS is, er, rarely necessary. It is actually one of the first candidates to be removed from CAR: and go to the Toolkit (EDIT: I can see that it is in both places - so it already moved to Toolkit but we forgot to delete it from CAR:, heh).

 

Its purpose is to ensure, that if a binary program loads a segment to RAM at $d800-$dfff, the data will actually go to that RAM when the transfer goes from a PBI device. Because normally during a transfer from a PBI device the $d800-$dfff is occupied by PBI ROM and nothing can be directly loaded there.

 

That said, I well realize that it should be rather solved inside SPARTA.SYS, so that such transfers get buffered (i.e. the data get loaded to the DOS buffers and then moved to the $d800-$dfff, not burst-loaded directly to the destination place).

 

But this problem is so rare that in practice no reasonable program suffers from this. So you can say that PBI.SYS is superfluous (although theoretically it should improve backward compatibility with programs written for XL/XE in pre-PBI era).

 

A side note de re PCLINK: PCLINK does not actually have to be a serial device. It is a serial device only because there is some infrastructure existing which allows to make a connection to a PC easily (namely SIO, POKEY, SIO2PC, USB). But if anyone ventures to build such a PBI device, the same protocol may serve for data exchange at much better speeds.

Edited July 31, 2016 by drac030

[flashjazzcat]

Rare, yes. I would suggest that compiling a segment with a load address of $D800-$DFFF is pretty inadvisable anyway? I understand that it should be possible on paper, but one wouldn't - for example - turn off the OS and attempt to load a segment to the Shadow RAM using the OS SIO routines? Although admittedly this might work with SDX since the SIO drivers are usually in RAM... but still.

 

Anyway thanks for explaining that, since I too has often wondered its purpose.

[drac030]

One can still move OS from ROM to RAM and then load something to overwrite the math-pack area.

[flashjazzcat]

True, although I prefer the load to main memory, disable ROM and move code approach.

[Bikerbob]

OK, understand the server part..

 

What about a protocol on the RespeQt side to access the Fat16 partiton.. and or Fat32 ... aka like the Altirra file browser?? having to open the 800 remove the CF card and back again would lead me to think there really is no benefit to the fat16 partition on the CF card. (USE RespeQt as the fileserver software - but the drive is the CF card???)

 

The PClink is a real game changer for using an old PC laptop as a server.. I love my incognito because its such cool tech for a 35 year old computer.. but makes the CF card kind of pointless if you have sio2 whatever and a server.

 

James

Edited July 31, 2016 by Bikerbob

[flashjazzcat]

Well, considering SIO2PC is currently limited to around 10KB/s, once you find you want to move 32MB of data to the Atari, moving the CF card from one machine to another isn't such huge inconvenience compared to waiting for 32MB to travel at - at best - 126Kb/s. Once the files are on the FAT16 partition and the card's in the machine, things are happening at more like 60KB/s.

 

Same goes with the loader, of course. Loading up 1 or 2GB of XEXs and ATRs is probably best done using your PC card reader.

 

Once the FATFS.SYS driver allows writes, I guess it will change the situation quite dramatically. As would a parallel SIO2PC device, as Konrad suggested, which has been kicked around as an idea for years but never materialised.

Edited July 31, 2016 by flashjazzcat

[kogden]

The PClink is a real game changer for using an old PC laptop as a server.. I love my incognito because its such cool tech for a 35 year old computer.. but makes the CF card kind of pointless if you have sio2 whatever and a server.

 

That's like saying:

 

"Ethernet is a game changer, we should just all move to diskless workstations and have a fileserver in the closet". While this is possible, it's never worked as well as people thought. Pointless for YOU maybe but for me doing everything over SIO would be painful.

 

Same goes with the loader, of course. Loading up 1 or 2GB of XEXs and ATRs is probably best done using your PC card reader.

 

Once the FATFS.SYS driver allows writes, I guess it will change the situation quite dramatically. As would a parallel SIO2PC device, as Konrad suggested, which has been kicked around as an idea for years but never materialised.

 

Most of the time I do my big transfers to my IDEPlus over SIO and just take the kids to McDonalds or something. Once the FATFS driver does writes, it may become the default filesystem I use on my IDEPlus LOL

 

Wouldn't a parallel SIO2PC device need some pretty serious software support Atari-side? If we're going that route, I think a PBI ethernet interface and a PCLink-over-Ethernet protocol would be even cooler.

[flashjazzcat]

That's like saying:

 

"Ethernet is a game changer, we should just all move to diskless workstations and have a fileserver in the closet". While this is possible, it's never worked as well as people thought. Pointless for YOU maybe but for me doing everything over SIO would be painful.

I mainly use PCLink and folder mounting (the latter generally being read-only) as a testing aid, with the server pointing at the cross-compiler's destination folder. This is quicker than copying an XEX onto a CF card and ferrying it back and forth. PCLink is also useful when I want to copy a few text files from the Atari to the server folder, which - again - doesn't necessarily warrant swapping cards or setting up ATRs. But when I want to fill up the loader's FAT partition with games and demos, nothing beats the PC's card reader.

 

Most of the time I do my big transfers to my IDEPlus over SIO and just take the kids to McDonalds or something. Once the FATFS driver does writes, it may become the default filesystem I use on my IDEPlus LOL

Presumably this is one reason Candle asked me to handle ATR mounting using FAT on the U1MB and Incognito. With IDE Plus (which I think requires ATRs to be hosted in SDFS formatted partitions) you could still copy a bunch of stuff to a FAT16 partition using the card reader, then use the FATFS.SYS driver on the Atari to at least facilitate fairly rapid copying of said content from FAT to a suitable SDFS partition.

 

Wouldn't a parallel SIO2PC device need some pretty serious software support Atari-side? If we're going that route, I think a PBI ethernet interface and a PCLink-over-Ethernet protocol would be even cooler.

I don't imagine it would be much different to a BIOS for a hard disk host adapter, but would need to support variable block sizes (up to some dozens of KB for PCLINK) across the parallel link. PBI is the way to go for Ethernet, IMO, as well, with plenty of math pack overlay ROM and RAM keeping the TCP/IP stack out of the Atari's hair, or handling as much as possible in FPGA.