My plans for Nextor v3 (warning: broken drivers ahead!)

Page 2/3
1 | | 3

By ducasp

Champion (315)

ducasp's picture

02-08-2020, 01:06

Yeah, basically you open the file, seek to size - 1, call ensure, and seek back to 0. One problem with this approach is that depending upon file size ensure will take quite a while and if you are in the middle of something that requires an acknowledge in a few seconds, it might not work (which is why I don't use it on my telnet client file transfer routines, as usually you have 1 to 3 seconds to acknowledge filebwas created and if you acknowledge before, data will come and you won't be writing to disk or sending ack to data, if you acknowledge after ensure the protocol time-out even before sending the first data packet).

By Pencioner

Scribe (1136)

Pencioner's picture

02-08-2020, 01:47

Well, didn't know that. Anyway, you can't change all software to use pre-allocation - there's a lot of legacy and non-open-source programs. Also, sometimes you don't know the file size beforehand... so in any case, free cluster search optimization would be a redeemer

By gdx

Prophet (3557)

gdx's picture

02-08-2020, 08:25

I am not in favor of an MSX-DOS2 incompatible Nextor. I prefer that nextor evolves slowly (but surely) even if the current flaws remain. Improvements like those mentioned by Grauw are sufficient. If Nextor 3 is incompatible, it will remain in the corner of curiosities like SymbOS even if it is as good or better.

If you don't have enough time to develop, skip Nextor 3 and set aside that time to improve Nextor 2. For me the main problem with Nextor 2 is the drivers that need some improvement/fixes.

Grauw wrote:

As a user I would also like FAT32 support. FAT16 is generally big enough (although I can fill up 4 GB with VGMs no problem), but many storage media come preformatted as FAT32, and finding the FAT16 formatting options on modern PCs can sometimes be a bit of a challenge.

It doesn't really matter as long as PCs continue to read or write FAT16. The Basic _FDISK instruction is there for that.

Pencioner wrote:

This problem exists not only in Nextor, but Fat16 driver for DOS2 by Okei has exactly the same issue

I think Nextor takes the same way as Okei to stay compatible.

Besides, since we talk about it from what I've seen of FAT16 support, I feel like this could have been implemented differently to be more compatible with FAT12. An improvement of this kind will be welcome even if we must be changed the software that has been done to FAT16.

By xavirompe

Resident (44)

xavirompe's picture

02-08-2020, 10:05

In my opinion is a good idea to go forward, and expand the Nextor's capabilities.
For me would be great to have file system that avoids the FAT translation, in order to deal with network drives easily, or even get a faster access to the USB drive files using the high level functions of the CH376 chip.

Filesystem driver means for me a excellent way to connect the MSX to an infinite sources of storage, using whatever as communication channel: serial, network, etc.
And about the drivers in RAM, what can I say??? whay not?, it will be an open door to develop more features with better support, great!

An finally, the FDD support, well I feel happy every time I ear the "click" when the floppy is inserted...

So Mr. Konamiman, I am ready to perform any test that you whant to do!

My suggestions:
* Hot plug support, to attach new drives on the fly.
* Boot from filesystem driver.

Thank you very much

By konamiman

Paragon (1067)

konamiman's picture

02-08-2020, 15:58

gdx wrote:

I am not in favor of an MSX-DOS2 incompatible Nextor.

I think you misunderstood my post Smile The incompatibilities I was talking about are at the driver level, not at the function calls level. Nextor 3 would be fully compatible with Nextor 2, and of course with MSX-DOS 2.

By Grauw

Ascended (9156)

Grauw's picture

02-08-2020, 16:34

It would also continue to interface with disk drives’ existing DiskROMs without needing to load special drivers for them, right?

By konamiman

Paragon (1067)

konamiman's picture

02-08-2020, 16:56

Grauw wrote:

It would also continue to interface with disk drives’ existing DiskROMs without needing to load special drivers for them, right?

Yo mean internal FDDs and other MSX-DOS kernels? Of course, that won't change.

By xavirompe

Resident (44)

xavirompe's picture

02-08-2020, 17:21

Just a question, what will happen with the MSXDOS1 embeded kernel?

By pgimeno

Master (188)

pgimeno's picture

02-08-2020, 17:35

Grauw wrote:

However it would be nice if a zero-length write would actually also allocate the file, but not write any contents. A zero-length write currently acts as a no-op.

In PC-DOS, a write of 0 bytes is not only able to extend the file, but also to shrink it.

http://spike.scu.edu.au/~barry/interrupts.html#ah40

By konamiman

Paragon (1067)

konamiman's picture

03-08-2020, 11:17

Pencioner wrote:

What i see as possible solution for FAT drivers - when searching for the free cluster, don't start from he beginning each call, but store the last succesfully found free cluster index in RAM and start from there. If end of drive is reached the start over from first one.

That's actually a pretty neat idea. That cached value, appropriately updated after each writing operation, could be kept until the volume changes, or the drive mapping changes, or content is deleted (and thus more free clusters become available).

Page 2/3
1 | | 3