Author Topic: UniDOS, the new multi-device AMSDOS replacement  (Read 17590 times)

0 Members and 1 Guest are viewing this topic.

Offline OffseT

  • CPC664
  • ***
  • Posts: 144
  • Country: fr
    • Futurs' Freeware Diffusion
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #75 on: 20:44, 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:

like
0
No reactions

Offline m_dr_m

  • 464 Plus
  • *****
  • Posts: 308
  • Country: gb
  • http://orgams.wikidot.com/
    • OrgaMS!
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #76 on: 15:53, 01 May 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?
like
0
No reactions

Offline m_dr_m

  • 464 Plus
  • *****
  • Posts: 308
  • Country: gb
  • http://orgams.wikidot.com/
    • OrgaMS!
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #77 on: 14:36, 02 May 21 »
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 !
« Last Edit: 14:39, 02 May 21 by m_dr_m »
like
0
No reactions

Online TotO

  • 6128 Plus
  • ******
  • Posts: 4.033
  • Country: fr
    • ?area=showdonations;u=4
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #78 on: 14:53, 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. :)
like
0
No reactions
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Offline m_dr_m

  • 464 Plus
  • *****
  • Posts: 308
  • Country: gb
  • http://orgams.wikidot.com/
    • OrgaMS!
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #79 on: 14:57, 02 May 21 »
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
like
0
No reactions

Offline OffseT

  • CPC664
  • ***
  • Posts: 144
  • Country: fr
    • Futurs' Freeware Diffusion
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #80 on: 01:34, 03 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.

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.
Unfortunately, a pointer is not a generic way to store the path (it could work for filesystems but it might not work for handlers).

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 !
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.

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
Both short and long/explicit syntaxes could exist. No reason to keep only a cryptic form just because it is of a frequent usage.
« Last Edit: 01:57, 03 May 21 by OffseT »
like
0
No reactions

Offline m_dr_m

  • 464 Plus
  • *****
  • Posts: 308
  • Country: gb
  • http://orgams.wikidot.com/
    • OrgaMS!
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #81 on: 10:19, 03 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.


like
0
No reactions

Offline OffseT

  • CPC664
  • ***
  • Posts: 144
  • Country: fr
    • Futurs' Freeware Diffusion
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #82 on: 12:33, 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
like
0
No reactions

Offline m_dr_m

  • 464 Plus
  • *****
  • Posts: 308
  • Country: gb
  • http://orgams.wikidot.com/
    • OrgaMS!
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #83 on: 13:27, 03 May 21 »
This 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?).

Keep 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?



like
0
No reactions

Offline m_dr_m

  • 464 Plus
  • *****
  • Posts: 308
  • Country: gb
  • http://orgams.wikidot.com/
    • OrgaMS!
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #84 on: 13:29, 03 May 21 »
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).
Wouldn't this node need the same buffers than AMSDOS, so we would RUN into the same issue?
like
0
No reactions

Offline OffseT

  • CPC664
  • ***
  • Posts: 144
  • Country: fr
    • Futurs' Freeware Diffusion
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #85 on: 14:13, 03 May 21 »
Yep 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.



Wouldn'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).
like
0
No reactions

Offline GUNHED

  • 6128 Plus
  • ******
  • Posts: 2.847
  • Country: de
  • Reincarnation of TFM
    • FutureOS - The quickest OS for the CPC and Plus
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #86 on: 19:01, 03 May 21 »
... correct with X-Mass NVRAM and ...
Where do you have nvRAM in the X-MASS?
How to access it?

like
0
No reactions
http://futureos.de --> Get the revolutionary FutureOS (Update: 2021.01.24)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.07.15)

Offline OffseT

  • CPC664
  • ***
  • Posts: 144
  • Country: fr
    • Futurs' Freeware Diffusion
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #87 on: 19:36, 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.
like
0
No reactions

Offline zhulien

  • 6128 Plus
  • ******
  • Posts: 886
  • Country: au
  • aka Vorax
    • 8bitology
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #88 on: 03:59, 04 May 21 »
What advantages are there for UniDOS over CubeDOS and vice versa?
like
0
No reactions

Offline m_dr_m

  • 464 Plus
  • *****
  • Posts: 308
  • Country: gb
  • http://orgams.wikidot.com/
    • OrgaMS!
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #89 on: 10:46, 04 May 21 »
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).
« Last Edit: 10:49, 04 May 21 by m_dr_m »
like
0
No reactions

Online TotO

  • 6128 Plus
  • ******
  • Posts: 4.033
  • Country: fr
    • ?area=showdonations;u=4
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #90 on: 12:33, 04 May 21 »
For me, compatibility/reliability is far more important than speed. I have the time on my CPC.
like
0
No reactions
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Offline m_dr_m

  • 464 Plus
  • *****
  • Posts: 308
  • Country: gb
  • http://orgams.wikidot.com/
    • OrgaMS!
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #91 on: 14: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.
like
0
No reactions

Offline OffseT

  • CPC664
  • ***
  • Posts: 144
  • Country: fr
    • Futurs' Freeware Diffusion
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #92 on: 15: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.



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.



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)
like
0
No reactions

Offline Ast

  • 6128 Plus
  • ******
  • Posts: 1.242
  • Country: fr
    • Amstrad cpc Website of Ast/iMPACT
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #93 on: 16:44, 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.
like
0
No reactions
_____________________

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 welcomed !

Offline m_dr_m

  • 464 Plus
  • *****
  • Posts: 308
  • Country: gb
  • http://orgams.wikidot.com/
    • OrgaMS!
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #94 on: 17:17, 05 May 21 »
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.





like
0
No reactions

Offline Ast

  • 6128 Plus
  • ******
  • Posts: 1.242
  • Country: fr
    • Amstrad cpc Website of Ast/iMPACT
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #95 on: 17:29, 05 May 21 »
Everything you detail already exists elsewhere for a while.  ;D
like
0
No reactions
_____________________

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 welcomed !

Offline m_dr_m

  • 464 Plus
  • *****
  • Posts: 308
  • Country: gb
  • http://orgams.wikidot.com/
    • OrgaMS!
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #96 on: 17:44, 05 May 21 »
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)
like
0
No reactions

Offline Ast

  • 6128 Plus
  • ******
  • Posts: 1.242
  • Country: fr
    • Amstrad cpc Website of Ast/iMPACT
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #97 on: 17:50, 05 May 21 »
Just read and try what i wrote in iMPdos post  :P
like
0
No reactions
_____________________

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 welcomed !

Offline GUNHED

  • 6128 Plus
  • ******
  • Posts: 2.847
  • Country: de
  • Reincarnation of TFM
    • FutureOS - The quickest OS for the CPC and Plus
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #98 on: 20:50, 05 May 21 »
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.
« Last Edit: 20:52, 05 May 21 by GUNHED »
like
0
No reactions
http://futureos.de --> Get the revolutionary FutureOS (Update: 2021.01.24)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.07.15)

Offline GUNHED

  • 6128 Plus
  • ******
  • Posts: 2.847
  • Country: de
  • Reincarnation of TFM
    • FutureOS - The quickest OS for the CPC and Plus
    • Awards
Re: UniDOS, the new multi-device AMSDOS replacement
« Reply #99 on: 20:50, 05 May 21 »
double post
like
0
No reactions
http://futureos.de --> Get the revolutionary FutureOS (Update: 2021.01.24)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.07.15)