News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_OffseT

UniDOS, the new multi-device AMSDOS replacement

Started by OffseT, 15:51, 24 January 21

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

OffseT

Quote from: m_dr_m on 15:46, 28 April 21
It's quite disturbing to see the X-Mass active for each floppy access. Makes you wonder if the right drive is selected.
I agree. Did you try to remove the X-Mass LED?  :laugh:


m_dr_m

Quote from: m_dr_m on 15:46, 28 April 21@Offset Fair enough! What about doing the switch gymnastic only at drive change?
E.g.:
|A <- Backup Unidos, put Amsdos
cat  <- No NVRAM access
cat  <- No NVRAM access
|B <- Restore Unidos.

E.g.: automatically do |disc before, |dos after?

m_dr_m

#77
On the other hand, |PATH doesn't do any access? That's sweet, but that indicates you store it in RAM? Isn't that wasted space? Also, limits max length of path.
Candy (and maybe others) did a nice thing: keep a pointer (32 bits) to the current dir, and reconstruct the path recursively from here.
Since we don't need to display the path often (actually, only if it changes), the extra accesses aren't bothering.


Request:
* |MKDIR alias for save"toto/" which would give back control (if I try to create a directory via save in BASIC, it stops the program)
* |CD alias for load"dir" (same reason + uniformity with other DOS)
* Access to parent dir (e.g. load"../dump")
* A list of current known issue and current requests + status !

TotO

Quote from: m_dr_m on 12:36, 02 May 21
Request:
* |MKDIR alias for save"toto/" which would give back control (if I try to create a directory via save in BASIC, it stops the program)
* |CD alias for load"dir" (same reason + uniformity with other DOS)
|MD and |CD instead. Or |MKDIR and |CHDIR if you like long command. :)
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

m_dr_m

Good point, I like uniformity too. Yet I also enjoy Morse entropy principle:


* Frequent commands should be short
* Less frequent commands can be long
Plus:
* Modifying commands should be explicit

OffseT

#80
Quote from: m_dr_m on 13:53, 01 May 21
E.g.: automatically do |disc before, |dos after?
This is actually equivalent to what's done everytime a CAS_* that needs to be redirected to the AMSDOS/ParaDOS call is done.

Keep in mind that two devices can be accessed at the same time (one input and one output) by now (and that it is planned to be expanded with an additional generic i/o file handling API set).
It means that you cannot leave UniDOS disabled betweens two CAS_* calls, just sitting for a file close. The best that could be done is a "suspended mode" with minimal UniDOS handling so that AMSDOS/ParaDOS context switching could be reduced. But it will lead to more internal complexity which I prefer to avoid for now.

At the end, the best solution will be to actually create a full featured "Floppy DOS Node" that will override the internal DFA/DFB drives (btw, overriding is already working). Finally, the internal wrapper to AMSDOS/ParaDOS ROM could then be deleted.

Quote from: m_dr_m on 12:36, 02 May 21On the other hand, |PATH doesn't do any access? That's sweet, but that indicates you store it in RAM? Isn't that wasted space? Also, limits max length of path.
Candy (and maybe others) did a nice thing: keep a pointer (32 bits) to the current dir, and reconstruct the path recursively from here.
Since we don't need to display the path often (actually, only if it changes), the extra accesses aren't bothering.
Unfortunately, a pointer is not a generic way to store the path (it could work for filesystems but it might not work for handlers).

Quote from: m_dr_m on 12:36, 02 May 21Request:
* |MKDIR alias for save"toto/" which would give back control (if I try to create a directory via save in BASIC, it stops the program)
* |CD alias for load"dir" (same reason + uniformity with other DOS)
* Access to parent dir (e.g. load"../dump")
* A list of current known issue and current requests + status !
The fact that SAVE/LOAD on directories stops the program is a feature.  8)  But I agree that it forces you to handle errors to be able to auto-resume, which is sometimes a bit overkill.
RSX aliases for creating and entring directories was discussed at some point, but it was finally not selected. Anyway, it could be added eventually.
BTW, parent dir access is already supported (Changement de répertoire).
About issues/features/etc. it might be added on the web site.

Quote from: m_dr_m on 12:57, 02 May 21Good point, I like uniformity too. Yet I also enjoy Morse entropy principle: * Frequent commands should be short * Less frequent commands can be long Plus: * Modifying commands should be explicit
Both short and long/explicit syntaxes could exist. No reason to keep only a cryptic form just because it is of a frequent usage.

m_dr_m

Quote from: OffseT on 23:34, 02 May 21
The fact that SAVE/LOAD on directories stops the program is a feature.   
Wat? It also stops the program on success, which is not consistent with load/save for binaries.



OffseT

Quote from: m_dr_m on 08:19, 03 May 21
Wat? It also stops the program on success, which is not consistent with load/save for binaries.
Details here: LOAD/SAVE sur des répertoires

m_dr_m

Quote from: OffseT on 23:34, 02 May 21This is actually equivalent to what's done everytime a CAS_* that needs to be redirected to the AMSDOS/ParaDOS call is done.
Yep that exactly the problem! For Orgams that's every 2kb, for Starkos it would be every byte (one hour to load?).

Quote from: OffseT on 23:34, 02 May 21Keep in mind that two devices can be accessed at the same time (one input and one output) by now
I though about that, but that's very rare. Even copiers bufferize.
That brings us back to the general principle: common use cases shouldn't be penalised to deal with rare cases.
You still have the control over CAS_ routines, no? So 'sitting' in |DISC mode while just one file is opened wouldn't be so complex, would it?




m_dr_m

Quote from: OffseT on 23:34, 02 May 21At the end, the best solution will be to actually create a full featured "Floppy DOS Node" that will override the internal DFA/DFB drives (btw, overriding is already working).
Wouldn't this node need the same buffers than AMSDOS, so we would RUN into the same issue?

OffseT

Quote from: m_dr_m on 11:27, 03 May 21Yep that exactly the problem! For Orgams that's every 2kb, for Starkos it would be every byte (one hour to load?).
I though about that, but that's very rare. Even copiers bufferize.
That brings us back to the general principle: common use cases shouldn't be penalised to deal with rare cases.
You still have the control over CAS_ routines, no?
So 'sitting' in |DISC mode while just one file is opened wouldn't be so complex, would it?
AMSDOS/ParaDOS wrapping is not required between every 2K buffers of ASCII files.

BTW, context switching speed is already quite good with Albireo NVRAM, correct with X-Mass NVRAM and it will be even better with Nova one.

Your general principle also applies here. Depends on the balance. Managing conditionnal context AMSDOS/ParaDOS activation would penalize all regular accesses just to gain a few speed on ASCII files from floppies, at cost of complexity too.
I'm quite convinced it is not a good idea to add this complexity just to optimize this corner case for now. It is not only a matter of CAS_* APIs, but also of RSX and BIOS calls.



Quote from: m_dr_m on 11:29, 03 May 21Wouldn't this node need the same buffers than AMSDOS, so we would RUN into the same issue?

This DOS node could comply with UniDOS memory management, and if required, it could handle additional memory in a system-friendly manner (like FatFs does).

GUNHED

Quote from: OffseT on 12:13, 03 May 21
... correct with X-Mass NVRAM and ...
Where do you have nvRAM in the X-MASS?
How to access it?

http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

OffseT

Quote from: GUNHED on 17:01, 03 May 21
Where do you have nvRAM in the X-MASS?
How to access it?
It is emulated either thru a file on the file system (default mode) or by using some raw sectors (fatfs.cache.on mode) which are located between the partition table and the first partition.

zhulien

What advantages are there for UniDOS over CubeDOS and vice versa?

m_dr_m

#89
I'm preparing an article with more details, but here are some cons:

CubeMDOS:

* Some critical bugs. I've reached a state when saving consistently crashes (in ROOT or in a DIR). YMMV
* No path handling for load/save.
* CAT nor sorted
* Less reactive, but that may change as @SOS is back :)


UniDOS:

* Slower on FAT32
* Much slower on floppy (for headerless files via CAS_WRITE_CHAR)
* Not as exhaustive for now (needs nodes for M4, Symbiface, HxC direct access).

TotO

For me, compatibility/reliability is far more important than speed. I have the time on my CPC.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

m_dr_m

To each its own, I'm used to reactivity on CPC!
Also, I use it extensively for coding.



Anyway, why not both? Reliable and fast.

OffseT

UniDOS is actually focussed on compatiliby and reliability, but also, it proposes a unique solution so that all existing hardwares could be used all together in the same manner.



For now, the FatFs node is actually a bit slow because it is a direct port of the FatFs C library using sdcc which produces the worst Z80 code I ever saw. Anyway, it is still faster than floppies.
There is room for optimization, it is just a matter of rewriting some of the routines in nice Z80 code.


The situation is quite different with Albireo node which is much faster (also because of the hardware facilities). It is faster for both filesystem management and for file read/write operations.


Nova node will help quite a lot FatFs node users, espectially in "FATFS.CACHE.ON" mode (which is the most compatible one). I'm working on it.
Albireo users won't see that much difference, but it will save write cycles on their SD card and add RTC clock support.


Quote from: m_dr_m on 12:27, 04 May 21
To each its own, I'm used to reactivity on CPC! Also, I use it extensively for coding. Anyway, why not both? Reliable and fast.

Both is the goal. But when you have to choose: first reliability, then the speed.
And Albireo node already achieves both quite nicely. 8)

Ast

Quote from: OffseT on 13:27, 04 May 21
UniDOS is actually focussed on compatiliby and reliability, but also, it proposes a unique solution so that all existing hardwares could be used all together in the same manner.


Unique ? I am not all right with that fact.
_____________________

Ast/iMP4CT. "By the power of Grayskull, i've the power"

http://amstradplus.forumforever.com/index.php
http://impdos.wikidot.com/
http://impdraw.wikidot.com/

All friends are welcome !

m_dr_m

Well, that gives a unified way to access files.


E.g. in Orgams, relative to current dir:
  LOAD"data/3d.dot"


Or for a fixed location:
  LOAD"ide:gfx/beeb.win"


When I want to backup a copy of a source:
  CONTROL-S "a:rgb.o"


It will be even more important with incoming IMPORTs.






Ast

Everything you detail already exists elsewhere for a while.  ;D
_____________________

Ast/iMP4CT. "By the power of Grayskull, i've the power"

http://amstradplus.forumforever.com/index.php
http://impdos.wikidot.com/
http://impdraw.wikidot.com/

All friends are welcome !

m_dr_m

Really? With Imdpos you have to do:


|copy,"fart/*.o",arbitrary_number_i_have_to_double_check,another_one


Rather than:


|copy,"fart/*.o","a:"  (source = current device with current path)
or
|copy,"ide:fart/*.o","fda:" (source = ide root, dest = explicit floppy 0)

Ast

Just read and try what i wrote in iMPdos post  :P
_____________________

Ast/iMP4CT. "By the power of Grayskull, i've the power"

http://amstradplus.forumforever.com/index.php
http://impdos.wikidot.com/
http://impdraw.wikidot.com/

All friends are welcome !

GUNHED

#98
You're not really going to use 'fda' as indicator for drive 'a' ??? ??

Seriously, please (all DOS coders) have a look at CP/M and maybe XDDOS (!COPY,"*.*","c:"). No need to become completely incompatible.

One other thing that bugs me: Now we do have five DOS for mass storage devices! Is our scene really that incapable of cooperation? You guys should eventually work better together.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

GUNHED

http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Powered by SMFPacks Menu Editor Mod