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 3 Guests are viewing this topic.

Targhan

One more thing: I believe this is out of the scope of UniDOS (you tell me), but it would be great to explore a DSK like a folder. But I don't think a CPC has the firepower to do that.
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

OffseT

Quote from: Targhan on 20:57, 06 February 21
Some remarks:
- A little note in the doc about FAT16 not working could help some people (like me :) ).
- It took me a bit of time to understand that ":" must be put when using the Drive command. ùdrive,"a","SD:" or "DFA:". Maybe a shortcut without ":" could be done? Anyway, there is no direct example in the doc about such simple command, you should add it.
- Also add an example like "load"DFA:"" to show how quickly one can change the drive.
I just didn't imagine one could use anything else than FAT32 for the SD card. :)


About |DRIVE, it takes a path as 2nd argument. "DFA:" or "SD:" is just a path to the root of a drive. In short, |DRIVE will behave exactly like LOAD on a directory except that you choose the logical drive to load on.
And yes, in fact, LOAD"DFA:" is just a normal LOAD on a path to the root of the drive too.


I will add some remarks in the documentation.  8)


Quote from: Targhan on 21:02, 06 February 21One more thing: I believe this is out of the scope of UniDOS (you tell me), but it would be great to explore a DSK like a folder. But I don't think a CPC has the firepower to do that.

Well, in fact, it is feasible to create a "DSK DOS Node" which could add DSK0:, DSK1:, ... DSK7: drives. And then, a RSX "|DSKMOUNT,<unit>,<path to file>" to choose which DSK to mount on which drive.
It is just a lot of work (DSK file format management plus AMSDOS emulation over DSK), but all the required mechanisms are in place from UniDOS. ;)


Anyway, it easier to extract files from DSK to directories and access them directly from there; faster also.  :P

SOS

Quote from: Targhan on 21:02, 06 February 21But I don't think a CPC has the firepower to do that.
Hmmm, an DSK-Emulation is from the speed more than a real floppy, as an USB/SD-MassStorage.
Yes, the CPC has the firepower, but the speed is "retro".

Targhan

Quote from: SOS on 07:04, 09 February 21Yes, the CPC has the firepower, but the speed is "retro".

The speed is not the problem I had in mind. To me, the problem is handling a 200k DSK file, not quite simple on CPC.
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

SOS

Quote from: Targhan on 09:25, 09 February 21To me, the problem is handling a 200k DSK file, not quite simple on CPC.
Correct ;-)

Offset said correctly
"It is just a lot of work (DSK file format management plus AMSDOS emulation over DSK)"
The convert from "Track/Head/Sector" to an LBA-Value is a little bit tricky.
When you want to do that, (Tip) use an hardware which have an reliable LBA-Read-Sector-Function (XMASS, SF2/3)
IMHO you will not get an success when you try to use FileI/O's for an DSK-Emulation

OffseT

#30
Performance whise, a DSK DOS node would remain faster than a real disk accesses.
Regarding memory, it should not require more memory than regular floppy handling (in fact, it should even require less).


When developping softwares dedicated to UniDOS (which is typically the case of the DOS node coding), you get rid of AMSDOS limitations and you can handle files in a "modern" manner (read/write/seek), which helps a lot when playing with data in the middle on files.


That said, I see little interest in mounting DSK on the CPC; in everyday usage, it is much more convenient to have a direct access to files from directories. At the end, DSK could totally disappear. :D


FYI: they already did a similar work on ORIC, where their Albireo-like driver allows access to files from TAP files stored on USB or MicroSD card.

SOS

Quote from: OffseT on 10:48, 09 February 21Regarding memory, it should not require more memory than regular floppy handling (in fact, it should even require less).
You need more memory as a normal floppy interface, e.g. LBA-Start of the DSK-File, DSK-Geometrics, ...

OffseT

Quote from: SOS on 12:05, 09 February 21
You need more memory as a normal floppy interface, e.g. LBA-Start of the DSK-File, DSK-Geometrics, ...


In fact, you don't have to care about LBA and all this kind of things. File handler is computed by the DOS node actually providing the DSK file (and for Albireo DOS node, it is done in hardware by the ch376 directly).
The DSK DOS node would just have to retain the full path of the DSK file and then to navigate into it to access the required inner file parts on-demand (handling AMSDOS file records and so on).
(in short: what they did on ORIC for TAP files)

But again, I see very little interest in handling DSK file since we can erradicate them. 8)

OffseT

For those who are interested, I already converted all the Crackers Velus compilation DSK into directories (obviously, only for discs with files, not |CPM ones).
It also includes multi-disk games to work in one single directory (for instance for Defender The Crown, Iron Lord, Santa Cruz, ...).


Thank you very much to Velus who kindly provided my their master archive, including their indexing tool! 8)


Just ping me by email to get it. :)




(means that I did a script which is capable to convert a bunch of DSK into directories, so that I could convert any kind of collections in one click; I can share it, but it in for AmigaOS-only)

m_dr_m



Besides DSKs, do you see a solution to preserve CAT Arts?

OffseT

Quote from: m_dr_m on 21:20, 13 February 21
Besides DSKs, do you see a solution to preserve CAT Arts?
CAT arts stored on floppies should work as-is.


Regarding CAT arts stored on medias using FAT file system, the situation is a bit more tricky.


From UniDOS point of view nothing is preventing you from storing CAT arts on FAT. UniDOS is also sorting and displaying files like AMSDOS.
I did some tests, and I was actually able to create special file names required for CAT arts with Albireo on USB/SD FAT file system.


But, the issue comes from the outside. It appears to totally lock Windows(TM) when it encounters such files on a USB stick (until the stick is removed).
That said, on Amiga (and hopefully on Linux too) it is not a issue and these files are displayed normally (of course, the CAt art itself is not visible, you just see files with weird names).


To work around this issue, I was thiking about adding a native support for CAT arts in UniDOS. It could be in the form of a file with a special name/type stored in directories. When present, this file could contain what to be displayed on screen instead of the CAT.


zhulien


With the DOS Nodes, DOSNode_GetFreeSpace returns 32 size in kilobytes, maximum of 64megabytes?  how would a mass storage like an SD card be handled?

zhulien

for DOSNode_OutWriteStream and DOSNode_WriteNVRAM, if writing beyond the end of the file, is an error given or should the file grow?  If growing, is it padded with anything?


GUNHED

Just an IMHO important hint for UniDOS.

This hardware here:
https://www.cpcwiki.eu/index.php/IDE8255

is the fastest way for mass storage on CPC until today.
Please do support this great interface too.
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: zhulien on 10:10, 17 February 21
With the DOS Nodes, DOSNode_GetFreeSpace returns 32 size in kilobytes, maximum of 64megabytes?  how would a mass storage like an SD card be handled?
Maximum is 4 TB.



Quote from: zhulien on 10:17, 17 February 21for DOSNode_OutWriteStream and DOSNode_WriteNVRAM, if writing beyond the end of the file, is an error given or should the file grow?  If growing, is it padded with anything?

Writing beyond end of file should make the file to grow. Padding might depend on actual file system restrictions.


Anyway, seek itself cannot go over end of file, so you can only make the file to grow from its end.
Maybe documentation should be improved in this regard.


There is no "SetFileSize" API yet; it might be added in the future.

zhulien

Thanks, with regard to the 2k non-volatile memory, am I correct in that we can have filesystem nodes that can provide a subset of full functionality by not implementing the non-volatile memory functions?  Also is it likely that one of the reserved 7 functions would be later used for a device status, such as... is it write protected, is it readonly (i.e. could be a CDROM or internet FS) so that developers can make software that behaves instead of just erroring?

OffseT

Quote from: zhulien on 00:00, 18 February 21
Thanks, with regard to the 2k non-volatile memory, am I correct in that we can have filesystem nodes that can provide a subset of full functionality by not implementing the non-volatile memory functions? 

Yes, each DOS node can implement only a subset of the APIs.


For instance a drive with no write capability could avoid both nvram and write routines.
A drive which is not a filesystem but a simple stream could avoid seek routines (it would be the case of a TAPE: or a SERIAL:).


UniDOS adapts its behavior depending on DOS node capabilities.


Quote from: zhulien on 00:00, 18 February 21
Also is it likely that one of the reserved 7 functions would be later used for a device status, such as... is it write protected, is it readonly (i.e. could be a CDROM or internet FS) so that developers can make software that behaves instead of just erroring?
DOSNode_GetStatus already gives this kind on information about drives/medias capabilities, which is then available for the final UniDOS user though the "cmd_device_info" command of CTRL-J BIOS.

zhulien

#42
Are extension nodes already working for UniDOS now?  I think UniDOS if you finish it is going to be the ultimate DOS for CPC... because no other gives the access to all devices (potentially) in a highly compatible way.


I just noticed that the Node extensions can support their own implementation of NVRAM - in theory then an AMSDOS compatible node could use floppies as NVRAM, a X-Mass Node could use a file within the X-Mass as NVRAM, a Raspberry Pi bridgeboard could use the Pi filesystem as NVRAM etc?  So as long as enough people creating Nodes support NVRAM then there should be plenty of simulated NVRAMs around?  Or does it need to be real NVRAM?

OffseT

#43
Quote from: zhulien on 01:28, 12 March 21
Are extension nodes already working for UniDOS now? [...]
Sure. The already published Albireo node is fully functionnal and stable.

A FAT node able to support all raw FAT-based devices is almost finished. It handles FAT12/16/32 over MBR or GPT partitionned hard disks. Beta testing should start shortly with initial support limited to IDE (Symbiface, X-Mass, ...). Anyone interested can contact me to join the test phase. :)


I'm also looking for someone who could help for a M4 Board node because I don't have nor the board neither the time, but I could provide active support. Creating this node should be quite straightforward btw (even easier than Albireo one).


Quote from: zhulien on 01:28, 12 March 21I just noticed that the Node extensions can support their own implementation of NVRAM. [...]

You are right. Any DOS node can provide its own NVRAM support in the way it wants (real NVRAM, using files, reserved tracks, or even a faked one located standard memory). UniDOS will use the first one it finds.


zhulien

I created a skeleton file to fill in all the code for an extension, what is the reason for returning statuses in the C flag?  I would have used Z flag.  Perhaps there is a smarter technique using C that I don't know?  I do like the consistency in your entry and exist though.

Targhan

I cannot speak for Offset, but using the Carry as a return flag is very common and convenient. You can set or reset it via SCF / OR A respectively, at the end of your function.
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

OffseT

Quote from: zhulien on 16:57, 20 March 21
I created a skeleton file to fill in all the code for an extension, what is the reason for returning statuses in the C flag?  I would have used Z flag.  [...]
Targhan is right, C flag is easy to use. But in most routines, you will see that both C and Z flags are used (C for feature availability and Z for actual feature status).


May I ask which extension you plan to support?

zhulien

Quote from: OffseT on 10:28, 21 March 21
May I ask which extension you plan to support?


Actually I am not sure yet, I am hoping it isn't too hard to create a virtual fs on a webserver.


It would be cool if people could register and creates their own managed folders, then CPC users can access those folders within the root of a virtual filesystem.


for me, the server-side is the easy part.


root (somewhere on the net)
- offsett
-- whatever (can be readonly or read/write)
- zhulien
-- whatever (can be readonly or read/write)


OffseT

Quote from: zhulien on 14:09, 21 March 21
Actually I am not sure yet, I am hoping it isn't too hard to create a virtual fs on a webserver.
Sounds interesting. 8)

m_dr_m

I was so dazzled by the doc I couldn't read it.


Are there some routines that allow to seek/read a file block in a guaranteed amount of time?
Use-case: having file versions of track-load demos (with e.g. music or 3d animations while loading).

Powered by SMFPacks Menu Editor Mod