The Nextor Work-In-Progress topic

Page 3/8
1 | 2 | | 4 | 5 | 6 | 7 | 8

By sd_snatcher

Prophet (3486)

sd_snatcher's picture

25-02-2014, 03:08

@msd
The APPEND command is similar, but it is intended for CP/M programs to easily find their OVL or other files they depend on. In example, directory listings will not show the files contained in the APPEND directories. You can use it to allow editors to access the edited files seamlessly as if they had directory support. SUBST provides exactly that.

Quote:

just remember that I am not writing any changes for the command interpreter (COMMAND2.COM) at all

@konamiman
Ok, I'll keep that in mind. But SUBST should qualify, since it's on MS-DOS it is an external utility. Smile

By msd

Paragon (1462)

msd's picture

25-02-2014, 08:26

@sd_snatcher: It works for every program using the FCB calls iirc. What kind of program you want to use that this is a problem? I usually just changed the working directory on a drive before starting a program that can't handle dirs.

By konamiman

Paragon (1157)

konamiman's picture

25-02-2014, 09:21

I think I got what the difference is.

APPEND is used by the OS whenever it receives a request to open a file. If the file is not present in the current directory, it will be searched for in the path supplied by APPEND.

SUBST on the other hand, would be used when searching for files. So you would ask your DOS 1 text editor to list all the files on drive G:, and you would get the contents of A:\FILES\TXT instead, since you would have executed SUBST G: A:\FILES\TXT previously.

It should be not very hard to implement. Not trivial either, but doable.

By sd_snatcher

Prophet (3486)

sd_snatcher's picture

25-02-2014, 15:26

@konamiman

Bingo! You got it right. Here are some examples that APPEND can't handle:

1) When you want to use PMEXT to decompress files to a given directory. It would go like this:

SUBST G: A:\GAMES\ROMS
PMEXT MYROMS.PMA G:

2) Editing pages with Dynamic Publisher
Note: Drive A: will contain STP files you want to use, but you want to keep your PCT files in a specific directory

SET APPEND=A:\APPS\DYNAPUBL
SUBST B: A:\FILES\MAGAZINE
CD A:\FILES\STP
BASIC A:\APPS\DYNAPUBL\DYNAPUBL.BAS

By msd

Paragon (1462)

msd's picture

25-02-2014, 16:12

Quote:

1) When you want to use PMEXT to decompress files to a given directory. It would go like this:

SUBST G: A:\GAMES\ROMS
PMEXT MYROMS.PMA G:

This example is only valid when MYROMS.PMA is also on G: There is no problem if the destination is on another drive than the source.

By Manuel

Ascended (18256)

Manuel's picture

25-02-2014, 17:07

I can't remember I ever had problems with PMEXT on MSX-DOS2...

By konamiman

Paragon (1157)

konamiman's picture

25-02-2014, 17:49

Indeed, PMEXT works fine in DOS 2 because it does not search files, it just creates them (unpacks the files to the current directory of the destination drive).

By Prodatron

Paragon (1801)

Prodatron's picture

13-04-2014, 18:33

Hi Konamiman, while debugging a MegaFlashRom SD-card driver for SymbOS I figured out, that either SymbOS detects the FAT-version in a wrong way or Nextors FDISK (which is called in Basic) is creating too large partitions.
When creating a partition with the maximum size, there are the following values in the boot sector of such a partition:
BPB_RootEntCnt = 512
BPB_BytsPerSec = 512
BPB_NumFats = 2
BPB_FATSz16 = 256
BPB_TotSec32 = 8387873

Now let's calculate:

RootDirSectors = ((BPB_RootEntCnt * 32) + (BPB_BytsPerSec – 1)) / BPB_BytsPerSec = 32
DataSec = TotSec – (BPB_ResvdSecCnt + (BPB_NumFATs * FATSz) + RootDirSectors) = 8387328
CountofClusters = DataSec / BPB_SecPerClus = 65526

So we have a CountofClusters of 65526.

According to this Microsoft document...
"Hardware White Paper - FAT32 File System Specification - FAT: General Overview of On-Disk Format - Version 1.03, December 6, 2000"
...every volume, which has a CountofClusters >= 65525 is a FAT32 volume.
So it seems, that there is a 2 clusters overhang, when FDISK selects the maximum size for a FAT16 partition.

Maybe I messed something up, but currently it seems, that FDISK doesn't use the correct maximum values?

By edoz

Prophet (2400)

edoz's picture

13-04-2014, 18:53

Cool that you are making progress on the driver Big smile

By konamiman

Paragon (1157)

konamiman's picture

14-04-2014, 14:43

Well, let's just take a look at the source code of FDISK and it says...

#define MAX_FAT16_CLUSTER_COUNT 65526

...so indeed, I'm guilty.

I'll patch it in the next release, but the already partitioned devices will require a fix. Decreasing the total sector count in the boot sector should be enough.

Page 3/8
1 | 2 | | 4 | 5 | 6 | 7 | 8