CPCWiki forum

General Category => Applications => Topic started by: OffseT on 16:51, 24 January 21

Title: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 16:51, 24 January 21
Futurs' is pleased to announce the very first release of UniDOS, the new AMSDOS replacement ROM with evolutive multi-device support.

All information can be found here:
UniDOS (https://translate.google.com/translate?hl=&sl=fr&tl=en&u=https%3A%2F%2Funidos.cpcscene.net%2Fdoku.php%3Fid%3Dfr%3Aaccueil%26redirect%3D1)
https://unidos.cpcscene.net
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 18:18, 24 January 21
Wow, great project and great doc !
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: HAL 6128 on 20:59, 24 January 21
What do you mean with:


"Important:On CPC6128, it is necessary to patch the motherboard to be able to deactivate the internal ROM number 7 (other CPC models do not have this problem)."
How is it done?
By the way: great concept. And extensions like: path, symbolic links etc...  :D
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 23:14, 24 January 21
What do you mean with:
"Important:On CPC6128, it is necessary to patch the motherboard to be able to deactivate the internal ROM number 7 (other CPC models do not have this problem)."
How is it done?
That's only needed for few CPC6128. Most of them can replace ROM 7 too.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 23:18, 24 January 21
Futurs' is pleased to announce the very first release of UniDOS, the new AMSDOS replacement ROM with evolutive multi-device support.

To unify everything (DOS like) is a great idea.
Well, I had the same idea over 30 years ago, it was to have one system for every know hardware expansion. However I decided for OS instead of DOS. Both has it's advantages.

It would be great to have UniDOS 'open' in a way that I can use it with FutureOS too. This would save work and ROM slots. Of course I can contribute with support for Vortex F1-S, F1-D and Dobbertin HD20 hard-disc if you're interested.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 12:50, 25 January 21
So, does
Code: [Select]
|dir,"**/3d*"work? (:



Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 16:11, 25 January 21
So, does
Code: [Select]
|dir,"**/3d*"work? (:
Not yet. Wildcards are only working for the final part of a path for now (drive:my/path/3d*)

What do you mean with: "Important:On CPC6128, it is necessary to patch the motherboard to be able to deactivate the internal ROM number 7 (other CPC models do not have this problem)." How is it done?
You have information about how to patch the more common CPC6128 motherboard revision here:
(basically: how to add a switch so that the internal ROM 7 can be disabled)
http://quasar.cpcscene.net/doku.php?id=electronique:rom7 (http://quasar.cpcscene.net/doku.php?id=electronique:rom7)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 16:48, 25 January 21
It would be great to have UniDOS 'open' in a way that I can use it with FutureOS too. This would save work and ROM slots. Of course I can contribute with support for Vortex F1-S, F1-D and Dobbertin HD20 hard-disc if you're interested.


What do you mean by 'open'?
Both UniDOS and DOS Nodes entry points are 'open' already.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 19:03, 25 January 21
Open in a way, that the source is available, or at least an entry point documentation.
Is it possible the the big link in the first post is broken? It points to itself seemingly.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 22:22, 25 January 21
Is it possible the the big link in the first post is broken? It points to itself seemingly.

Actually, it seems to be broken when using some browsers (here it is working with Wayfarer but links to itself with Odyssey, maybe there is the same issue with some PC browsers).

Basically, it should open a Google Translate of https://unidos.cpcscene.net
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: pelrun on 08:13, 26 January 21
There's a forum bug that appears to affect links where the displayed text isn't the URL, randomly changing the link destination to other URL's that have been posted. Putting the URL directly into the message appears to always work.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Sykobee (Briggsy) on 13:01, 26 January 21
Excellent work. This is just what the CPC needs.


I have a 464 with Albireo (and DDI-1 or DDI-4 depending on which one decides to work on the day), so will have to wait for the 464 compatible version, and maybe get a flash rom thingy for the M4 finally.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 03:08, 27 January 21
Futurs' is pleased to announce the very first release of UniDOS, the new AMSDOS replacement ROM with evolutive multi-device support.

All information can be found here:
UniDOS

Sounds great - seems more than just myself wants this... any chance to collaborate to come up with a single standard solution?

https://www.cpcwiki.eu/forum/programming/cpc-drivers/

https://www.cpcwiki.eu/forum/programming/driver-roms/


It would be great if there was a standardized solution to drivers on CPC - rather than a PowerUP WarpOS situation or the current hodge bodge of incompatible solutions.  It is a good time to do it given the huge number of awesome hardwares over the past few years.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 03:12, 27 January 21
I propose we create a group of people with a goal to achieve a common goal - someone to maintain the tech docs website, a small group to work on the tech design, and spread a bit of the driver development / proof of concepts around.  OffseT? m_dr_m? Prodatron? and hardware creators themselves will hopefully follow the driver standard.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 19:51, 29 January 21
It would be great if there was a standardized solution to drivers on CPC - rather than a PowerUP WarpOS situation or the current hodge bodge of incompatible solutions.  It is a good time to do it given the huge number of awesome hardwares over the past few years.
UniDOS is a standard proposal at DOS level, not at driver level. And the main purpose is of course the AMSDOS compatibility.

Some standard drivers could be also created to help DOS node developpers, but it might be a bit overkill. Maybe the point is rather to create filesystem libraries (for FAT or whatever) with configurable read/write routines, so that several DOS nodes could share the same code (for instance the ones for IDE and for Ram Disk could).

But this was totally out of the scope of UniDOS (which is a DOS level abstraction), and also out of the scope of Albireo DOS node since all filesystem support is done in hardware by the Albireo card.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 20:01, 29 January 21
Of course I can contribute with support for Vortex F1-S, F1-D and Dobbertin HD20 hard-disc if you're interested.
Of course, the more DOS nodes we will have, the best it will be. 8) 
But I also guess that most people interested by UniDOS will ask for DOS node related to new school expansions that are easy to obtain instead of these good old ones which are hard to get.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 20:43, 29 January 21
Of course, the more DOS nodes we will have, the best it will be. 8) 
But I also guess that most people interested by UniDOS will ask for DOS node related to new school expansions that are easy to obtain instead of these good old ones which are hard to get.
Very true! It's a pity that nobody does 'clones' of the old stuff. Well, since software there already.
I need to have to look up how DOS nodes and all that work. Guess I wait until there is some version out, which will not change too much in future. Makes the work more easy, and as you told interest may be quite small.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 13:09, 30 January 21
UniDOS is a standard proposal at DOS level, not at driver level. And the main purpose is of course the AMSDOS compatibility.

Some standard drivers could be also created to help DOS node developpers, but it might be a bit overkill. Maybe the point is rather to create filesystem libraries (for FAT or whatever) with configurable read/write routines, so that several DOS nodes could share the same code (for instance the ones for IDE and for Ram Disk could).

But this was totally out of the scope of UniDOS (which is a DOS level abstraction), and also out of the scope of Albireo DOS node since all filesystem support is done in hardware by the Albireo card.


I think the approach from an AMSDOS compatibility point of view is the best option, so UniDOS will be awesome and likely the preferred new DOS.  If there is enough room on the ROM (or ROMS), then standard routines for developers would be awesome too.  Support for mass storage and floppies (and even TAPE) is a must.  At least reading from TAPE so it isn't too hard to transfer from tape to SDCARD for example. 


How is UniDOS to be configured for each system?  Does it autodetect different hardware?  i.e. GOTEK in mass storage mode vs floppy emulation mode? SSD on X-Mass? SD Cards on Symbiface 2 or M4?  Virtual drives over Wifi?  Perhaps inbuilt support for GR8CLOUDSERVER?

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: roudoudou on 15:02, 30 January 21
If there is enough room on the ROM (or ROMS), then standard routines for developers would be awesome too.
CPC can manage up to 256 roms :D
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 15:25, 30 January 21
How is UniDOS to be configured for each system?  Does it autodetect different hardware?  i.e. GOTEK in mass storage mode vs floppy emulation mode? SSD on X-Mass? SD Cards on Symbiface 2 or M4?  Virtual drives over Wifi?  Perhaps inbuilt support for GR8CLOUDSERVER?
UniDOS drives are dynamically handled; you will see them only if the related hardware/network was detected.
For hardwares with multiple modes/configuration, such as Albireo or GOTEK, it is up to the DOS node to add the required configuration RSX.

About the tape handling, a TAPE: drive is already implemented internally, but it was disabled in this first release because it required more testing. It will hopefully be activated in the next release, and like floppy discs related drivers, it is also auto-detected (means that TAPE: won't show on 6128plus, unless you manually soldered one on the mainboard :P ).

CPC can manage up to 256 roms :D
UniDOS DOS nodes are only detected within the first 32 ROMs. But it is something which could be expanded in the future.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Targhan on 13:15, 06 February 21
@OffseT (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1826) I tested your amazing work, but... cannot make it work.

I have a CPC 6128, not patched. My ROM config is:
ROM 4: ZERO
ROM 5: ALBIREO
ROM 6: UNIDOS
(plus others)

I have the Albireo plugged in, and the FlashGordon for the ROMs.

The CPC boots and writes "*Error: UniDOS found no NVRAM*, so it seems the "DOS Nodes" are not found... I thought it could be a hardware problem from the Albireo, but I tested it using AT2 (serial communication) and it works perfectly.
Plus since I installed the ZERO rom, it should work anyway.

Any idea? Thanks!
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 20:16, 06 February 21
The CPC boots and writes "*Error: UniDOS found no NVRAM*
Do you have the MicroSD card installed? (Albireo DOS Node stores NVRAM on the SD Card).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Targhan on 20:36, 06 February 21
Do you have the MicroSD card installed?
Yes, I used the SDCard I was using in the M4 board, so I'm sure it's working fine.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Targhan on 21:14, 06 February 21
Ah! The SDCard was in FAT16. I formatted to FAT32 and there is no warning anymore (2 seconds of booting, though). I'll explore UniDOS a bit further!
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Targhan on 21:57, 06 February 21
Ok! It seems to work pretty great!!

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 tested the UMS with a USB key, it works perfectly.

All in all, this is really great, you did a fantastic work. Now I'd like to use more the Albireo, so I should knock at Pulko's door :).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Targhan on 22:02, 06 February 21
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.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 12:51, 08 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)


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.

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
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: SOS on 08:04, 09 February 21
But 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".
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Targhan on 10:25, 09 February 21
Yes, 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.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: SOS on 10:54, 09 February 21
To 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
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 11:48, 09 February 21
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.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: SOS on 13:05, 09 February 21
Regarding 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, ...
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 13:31, 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)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 14:51, 09 February 21
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)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 22:20, 13 February 21


Besides DSKs, do you see a solution to preserve CAT Arts?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 19:24, 14 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.

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 11: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?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 11:17, 17 February 21
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?

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 16:37, 17 February 21
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.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 17:44, 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.



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?

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.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 01: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?  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?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 18:05, 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.



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.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 02:28, 12 March 21
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?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 16:11, 16 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).


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

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 17: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.  Perhaps there is a smarter technique using C that I don't know?  I do like the consistency in your entry and exist though.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Targhan on 23:06, 20 March 21
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.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 11:28, 21 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?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 15:09, 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)

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 11:16, 22 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)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 14:22, 08 April 21
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).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 19:35, 08 April 21
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).
Yes, there are some routines to seek/read or seek/write into files.
The amount of time will obviously depend on the size of the block and on the node on which the file is opened.
For instance, seek/read on Albireo node is much faster than on FatFs/X-Mass node.
Anyway, it could be considered that any "modern" node will be faster than floppies.


Please also note that seek is not possible on all medias. Tape or serial don't allow seek operation (you can know about the current drive capabilities with the DEVICE INFO routine).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 19:39, 08 April 21
Also, for your information, all nodes that were created for now (both released one and upcoming ones) are operating with interrupts enabled.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 12:02, 09 April 21
Wait, what? Even FDC based nodes? How does it work?
For the other devices, the transfert can be interrupted/resumed? Is there a max time allowed to fetch the data?


Another question: Can `|COPY` use a directory as source? The doc contradicts itself on this point.

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 17:44, 09 April 21
Wait, what? Even FDC based nodes? How does it work?
I was speaking about actual nodes for new hardwares only (Albireo, X-Mass, M4, ...).


In Fact, there is no FDC based node for now (legacy floppy disc drives access is done through AMSDOS ROM, which is obviously disabling interrupts).
But sure, when one will me created (to handle HxC in direct mode for instance), it will have to disable interrupt at some point.

I am thinking about providing information related to interrupt handling in the DEVICE INFO status; so that a program could know if interrupts will be disturbed or not by drive accesses.

For the other devices, the transfert can be interrupted/resumed? Is there a max time allowed to fetch the data?

Not for now.

Another question: Can `|COPY` use a directory as source? The doc contradicts itself on this point.

|COPY is limited to single file copy for now. It will be expanded to a full featured copy later.
In the meantime, a dual-lister graphical copier should be available too (DOpus / FileMaster style).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 20:13, 10 April 21
Well, IMHO it would be better to use ParaDOS instead of Amsdos, bigger floppy formats are a prerequisite for efficient work.


BTW: For FDC data transfer every 25 us a byte needs to be written/read to/from FDC.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 11:28, 11 April 21
Well, IMHO it would be better to use ParaDOS instead of Amsdos, bigger floppy formats are a prerequisite for efficient work.
As stated on the web site, both AMSDOS and ParaDOS are already supported by UniDOS (and a fixed ParaDOS version is available which is able to work in any ROM slot, not only 0, 6 or 7).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 15:03, 13 April 21
Great!
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 11:18, 19 April 21
UniDOS 1.10 is now available! 8)


This new version features:
All information can be found here:
UniDOS (https://translate.google.com/translate?hl=&sl=fr&tl=en&u=https%3A%2F%2Funidos.cpcscene.net%2Fdoku.php%3Fid%3Dfr%3Aaccueil%26redirect%3D1) (english Google translate)
https://unidos.cpcscene.net (https://unidos.cpcscene.net) (français)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Targhan on 11:48, 19 April 21
Wow! You did it very quickly! I don't have Xmass though to test the latest node, too bad :).
(small typo found in the doc: "qu'elle être omise une fois le disque formaté.". Not very french :)).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 22:08, 19 April 21
Wow! You did it very quickly! I don't have Xmass though to test the latest node, too bad :) .
(small typo found in the doc: "qu'elle être omise une fois le disque formaté.". Not very french :) ).
In fact it was finished about one month ago already, but I wanted to test it correctly before a release. ;D


It was quickly done because the code is based on FatFs which was converted to Z80 bizarre assembler using sdcc, and then to regular assembler thanks to a tool from No Recess.
The hard part was to make all this ugly code to fit in ROMs, and to handle the insane stack usage of FatFs... and also that I do not have a X-Mass.  :P
(that's the reason why I had to create a X-Mass emulation plugin for ACE in the first place).


Anyway, the typo is fixed. Thx.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 23:01, 20 April 21
The sdcard device,  is that for m4 cards or another sdcard reader?


Also is the usb device compatible with mini booster and HxC native?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 23:05, 20 April 21
I long for the day the following are all supported so all can be used at the same time...


- floppy a and b (supported)
- SD on M4 (?)
- xmas 128mb and 512mb (supported?)
- HxC native mode for FDA and FDB
- USB sticks (supported?)

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 15:35, 21 April 21
The sdcard device,  is that for m4 cards or another sdcard reader?

Also is the usb device compatible with mini booster and HxC native?
Supported devices are listed on download page of https://unidos.cpcscene.net (https://unidos.cpcscene.net)

Basically...

Already supported:
Being worked:
Nice to have:That said, do not expect myself to code all the DOS nodes for all the devices. First I do not own all the existing devices and second I have other projects on the way.

Anyway, SDK for DOS nodes available and fully documented, and I am always available to provide support to anyone willing to code new DOS nodes. To make it short: we need your help to support as much hardware as possible.

The goal remains of course to have one single AMSDOS-compatible DOS to handle all the existing hardware, so that software coders won't have to care about which hardware is being used.
 
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 23:08, 22 April 21
What is the current expected behaviour if using an M4 (with the M4 ROM) and UniDOS?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 10:15, 23 April 21
What is the current expected behaviour if using an M4 (with the M4 ROM) and UniDOS?
No idea. But I guess it won't fit very good.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 22:03, 23 April 21
No idea. But I guess it won't fit very good.
The M4 board is probably by far the most often sold expansion for the CPC during the last 30 years (more than 1000 units). Also the M4 provides LBA sector reading / writing (all you need for FAT32).
IMHO you can't name your DOS with the label UniDOS without M4 support.  ;) :)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 22:34, 23 April 21
The M4 board is probably by far the most often sold expansion for the CPC during the last 30 years (more than 1000 units). Also the M4 provides LBA sector reading / writing (all you need for FAT32).
IMHO you can't name your DOS with the label UniDOS without M4 support.  ;) :)
M4 support will come with a neat M4 DOS Node. There is no reason to mess everything up by trying to make it work with the M4 ROM which is not designed for multi-devices at all.
Also, there is no need to deal with FAT32, AFAIK M4 have direct file support just like Albireo.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 12:38, 26 April 21


Below logic so far to get an understanding of how a node logic could be, does it look right?


Code: [Select]

var nvram_opened = false;
var nvram_offset = 0;
var nvram_start = 0;
var nvram_size = 128;


// Initializes the DOS node
//
// Enter - D = -1
// E = -1
// Exit - If Carry = 1 then the node has been initialized
// If Z then a non-volatile memory manager is available in this node (2K mini)
// Only the non-volatile memory of the first node to have it is used by the UniDOS, in this case:
// If D is modified then the value is used as the default reader number in A
// If E is modified then the value is used as the default reader number in B
// If NZ then no non-volatile memory manager is available
// A = error code
// If Carry = 0 then the node could not be initialized
// Altered - AF, DE
    this.init = function(d, e)
{
nvram_opened = false;
nvram_offset = 0;
 
c = 1; // initialised
z = 1; // non-volatile memory available
a = 0; // no error

return a, c, z;
};

// Checks if a drive name matches a drive managed by our DOS node
//
// Enter - HL = pointer to drive name
// (if set to certain characters, bit 7 must be ignored)
// C = length of drive name
// Exit - If Carry = 1 a match was found
// A = number of the physical reader (from 0 to 7)
// If Carry = 0 no match was found
// Altered - AF
    this.checkDrive = function(hl, c)
{
if (hl == 'n')
{
c = 1; // found the drive
a = 0; // it is drive 0
}
else
{
c = 0; // drive not found
}

return a, c;
};

// Returns the status of a reader
//
// Enter - A = Reader number
// Exit - If Carry = 1 a status could be retrieved
// A = Player status (see Media_ * flags)
// Bit0 = 1 if media is available on this drive
// Bit1 = 1 if the media manages the directories
// Bit2 = 1 if the media is write protected
// Bit3 = 1 if the media is removable
// Bit4 = 1 if the media is a stream (linear read / write only)
// The management of the $$$ and BAK files is then deactivated.
// Bit5 = 1 if the media is accessible via the new AlbiDOS APIs (always set to 1)
// The other bits are not used
// If Carry = 0 then the reader is unknown and no status could be retrieved
// A = 0
// Altered - AF
    this.getStatus = function(a)
{
a = 0x00000011;
c = 1;
return a, c;
};


// Returns the name corresponding to a physical drive
//
// Enter - A = reader number
// DE = address of an 8-byte buffer where to copy the name
// Exit - If Carry = 1 the name was found
// DE points to the first character after the end of the string copy
// (the stored string is terminated with bit 7 to 1)
// If Carry = 0 the name was not found and the buffer was not modified
// Altered - AF, DE
    this.getName = function(a)
{
if (a == 0)
{
c = 1; // found the drive
de = 'n'; // it is drive n
}
else
{
c = 0; // drive not found
}

return a, c;
};

// Returns the description corresponding to a physical drive
//
// Enter - A = physical drive number
// DE = address of a 32-byte buffer where to copy the description
// Exit - If Carry = 1 a description was found
// DE points to the first character after the end of the string copy
// (the stored string is terminated with bit 7 to 1)
// If Carry = 0 no description was found and the buffer was not modified
// Altered - AF, DE
    this.getDesc = function(a)
{
if (a == 0)
{
c = 1; // found the drive
de = 'net drive'; // it is drive n
}
else
{
c = 0; // drive not found
}

return a, c;
};


// Change the protection bits of a file (NewAPI only)
//
// Enter - A = physical drive number
// HL = pointer to standard name
// DE = pointer to the normalized path
// B = Protections to be modified
// C = New protections
// Bit 0 - Read only
// Bit 1 - Hidden
// Bit 5 = Archived
// The other bits are ignored
// The pointed memory is in the current ROM / RAM space
// Output - If Carry = 1 the routine is supported by this reader
// If Z then the protections have been modified
// If NZ then the protections could not be modified
// A = error code
// If Carry = 0 then the routine is invalid for this reader
// Altered - AF
    this.setProtection = function(hl, de, b, c)
{
c = 0; // not supported
return c;
};

// Open non-volative memory (NewAPI only)
//
// Enter - C = opening mode
// If 0 then the non-volatile memory with its current content must be opened
// If 1 then the non-volatile memory must be reset to zero before opening
// Exit - If Carry = 1 then the DOS node offers non-volatile memory service
// If Z then the non-volatile memory has been opened and is ready to be manipulated
// If NZ then an error has occurred
// A = error code
// If Carry = 0 then the DOS node does not offer non-volatile memory
// Altered - AF
    this.openNVRAM = function(c)
{
if (c == 1)
{
clear the NVRAM
}

nvram_opened = true;
nvram_offset = 0;
c = 1;
z = 1;
a = 0;

return a, c, z;
};

// Closes and updates the contents of non-volatile memory (NewAPI only)
//
// Entrance - None
// Exit - If Carry = 1 then the DOS node offers non-volatile memory service
// If Z then the non-volatile memory has been updated
// If NZ then an error has occurred
// If Carry = 0 then the DOS node does not offer non-volatile memory
// Altered - AF
    this.closeNVRAM = function()
{
if (nvram_opened)
{
TODO: update NVRAM contents;
nvram_opened = false;
z = 1;
}
else
{
z = 0;
}
c = 1;

return c, z;
};

// Reads data from non-volatile memory (NewAPI only)
//
// Input - HL = address where to write the read data
// DE = number of bytes to read
// Exit - If Carry = 1 then the DOS node offers non-volatile memory service
// If Z then the data has been read
// DE = number of bytes actually read
// If NZ then an error has occurred
// A = error code
// If Carry = 0 then the DOS node does not offer non-volatile memory
// Altered - AF, DE
    this.readNVRAM = function(hl, de)
{
if (nvram_opened)
{
if ((nvram_start + nvram_offset + DE) < nvram_size)
{
TODO: transfer DE bytes from nvram to address HL;
z = 1;
}
else
{
z = 0;
a = out of bounds;
}
}
else
{
z = 0;
a = not opened;
}

c = 1;


return a, c, z;
};


// Writes data to non-volatile memory (NewAPI only)
//
// Input - HL = address where the data to be written is located
// DE = number of bytes to write
// Exit - If Carry = 1 then the DOS node offers non-volatile memory service
// If Z then the data has been written
// DE = number of bytes actually written
// If NZ then an error has occurred
// A = error code
// If Carry = 0 then the DOS node does not offer non-volatile memory
// Altered - AF, DE
    this.writeNVRAM = function(hl, de)
{
if (nvram_opened)
{
if ((nvram_start + nvram_offset + DE) < nvram_size)
{
TODO: transfer DE bytes from HL to nvram;
z = 1;
}
else
{
z = 0;
a = out of bounds;
}
}
else
{
z = 0;
a = not opened;
}

c = 1;


return a, c, z;
};

// Change position in non-volatile memory (NewAPI only)
//
// Enter - DEHL = new position
// Exit - If Carry = 1 then the DOS node offers non-volatile memory service
// If Z then the new position could be reached
// If NZ then an error has occurred
// A = error code
// If Carry = 0 then the DOS node does not offer non-volatile memory
// Altered - AF
    this.seekNVRAM = function(de, hl)
{
if (nvram_opened)
{
if (DEHL is within nvram)
{
TODO: seek to position DEHL in nvram;
z = 1;
}
else
{
z = 0;
a = out of bounds;
}
}
else
{
z = 0;
a = not opened;
}

c = 1;


return a, c, z;
};


The other functions I haven't yet finished looking at... for seekNVRAM, what is inside DEHL? 
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 12:12, 28 April 21
for seekNVRAM, what is inside DEHL? 

The address at which the next Read/Write must occurs.
E.g. if the seekNVRAM is invoked with DEHL = &4f0, and then your DOSNode_ReadNVRAM is called with DE = 2, HL = &8000, you must write the word at &4f0 from your NVRam at &8000 in CPC memory.

Note: you normally don't have to code those routines (especially for an Network FS!), since it's likely another node is already supporting the NVRAM is an efficient way. Unidos needs only one NVRAM, and if your node wants to store persistent info, I think we should come up with a better solution (e.g. new routine exposed by Unidos).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 12:34, 28 April 21
I also have a question:


* For now the FatFS seems dedicated to X-Mass. How would one reuse the FAT32 handling for another device?
I was expecting to see 'Device Nodes' exposing read/write_sector, with a |DRIVE (mount) version able to bind a mount point to a (FS, hard device) custom couple.


And now for something completely different: it seems the NVRAM is accessed quite a lot! E.g. for a cat on floppy disc: one time at the beginning, and one time before displaying the number of free Kb. Why is that so?


Frankly, I would prefer all work memory to rely on CPC memory (I don't really care about HIMEM being lower!) and/or reusing some unused firmware space (I never use tapes!).
I know tradeoffs are difficult and you prioritised compatibility, but for a CPC developper, that looks a suboptimal solution has been picked just to deal with rare corner cases.


A solution might be to be only switch to high compatibility when ROM7 is re-init alone (e.g. for Games/Demos loaders).
Also, for programs like OCP, the alternative would be to patch them or obsolete them!


Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 13:48, 28 April 21
* For now the FatFS seems dedicated to X-Mass. How would one reuse the FAT32 handling for another device?
I was expecting to see 'Device Nodes' exposing read/write_sector, with a |DRIVE (mount) version able to bind a mount point to a (FS, hard device) custom couple.
A few more routines needs to be exposed than just read/write sector. You also need to be able to initialize the device, to probe its geometry, to format it. FatFs also requires about 600 bytes of memory for each new mounted drive, which is tricky to deal with in an AMSDOS compatible manner. :(

That's why for now FatFs is restricted to one single IDE device. Of course, it will be expanded in the future, that's also the reason why the ROMs are splitted in three parts.
One which is the FatFs itself.
One which will contain drivers for supported devices (at some point it could become also a modular ROM handling sub-rom/ram modules).
One which is containing all the tools for disc partitionning and formatting.

But before expanding FatFs support to new devices, I guess that we first have to optimize FatFs itself. The current code is just some adapted sdcc output which is quite ugly, slow and stack killer.
In fact, I'm just surprised it works that good. :P

And now for something completely different: it seems the NVRAM is accessed quite a lot! E.g. for a cat on floppy disc: one time at the beginning, and one time before displaying the number of free Kb. Why is that so?
True. NVRAM is used for two different things.
First it is used to store actual UniDOS configuration and current context (that's the main usage).
Second, it is used as a swap memory area to deal with AMSDOS/ParaDOS memory buffers which are stored at the same address that UniDOS ones for compatibility reasons.

That's why it is used when accessing floppy discs. 8)

Frankly, I would prefer all work memory to rely on CPC memory (I don't really care about HIMEM being lower!) and/or reusing some unused firmware space (I never use tapes!).
I know tradeoffs are difficult and you prioritised compatibility, but for a CPC developper, that looks a suboptimal solution has been picked just to deal with rare corner cases.

Parts of tape memory area is already used by UniDOS for internal stuff. Basically, almost all possible spare memory which is not breaking compatibility is already used. ;D


But well, compatibility is not related to "rare corner cases". Touching HIMEM, even about a few bytes, will prevent hundreds of softwares from working.
The goal was not to create a DOS which would work only with dev tools (which is basically what happens when HIMEM is changed).
You don't want to switch back to floppies to play games, to use Digitracker, Starkos, Soundtracker DMA :o , and so on.
The goal is really to use all of this in one single AMSDOS compatible enviroment... and directly from files (we don't want those nasty DSK anymore).


That said, you are right, this is not optimal (in fact, mostly when dealing with AMSDOS buffer cache while accessing floppy discs, other use-cases have almost no penality performance-wise). Anyway, the Nova card from PulkoMandy was created to get rid of this "on-disk" NVRAM while keeping a high compatilibty level. 8)
It is particulary valuable for guys like you and me which are still using they CPC for development purpose, especially when using FatFs (Albireo users won't notice big performance boost at all, but it will still save write cycles on SD card).


A solution might be to be only switch to high compatibility when ROM7 is re-init alone (e.g. for Games/Demos loaders).
Unfortunately, the compatibility issue is not limited to ROM7 reinit. A lot of softwares (notably with Basic loaders) won't reinit ROM7 but will require the default memory layout to work properly.
Some of them are even directly using ROM routines which are totally undocumented... which is for now the main UniDOS compatibility flaw, even when it is installed as ROM7.

Also, for programs like OCP, the alternative would be to patch them or obsolete them!

I agree, in a perfect world we could patch everything, and we would recode old-fashioned softwares in a smart manner.
But it won't happen.  :'(  Just look at modern games and softwares, their compatibility is often worse that old ones!
That said, I already created a patched version of OCP which works when UniDOS is not stored in ROM7. ;D
But this was an easy patch. Patching it to work on a system where memory is dynamically allocated is another story.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 13:56, 28 April 21
Note: you normally don't have to code those routines (especially for an Network FS!), since it's likely another node is already supporting the NVRAM is an efficient way. Unidos needs only one NVRAM, and if your node wants to store persistent info, I think we should come up with a better solution (e.g. new routine exposed by Unidos).
That's true. NVRAM is a peticular feature which a network DOS node could/should avoid.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 16:26, 28 April 21
I was thinking the NVRAM would be used to store settings for example, I didn't think it was constantly read and written to so many times.  This does mean a bit of rethinking... i.e. loading the security token from floppy disc instead of NVRAM - but having said that, you did say something else (likely faster than the network) would have an NVRAM, so all should be good still... saves me coding the NVRAM stuff - but that bit does appear somewhat straight forward.


With regard to FatFS... could it be possible to have 3 types of UniDOS nodes - type 1 which essentially is what we have now to handle files, directories, reading, writing, and type 2 which is a FS handler which can be 'chosen' if the defaults are not wanted (type 1 always goes through a type 2), and type 3 which is a trackdisc handler (which can optionally be communicated directly).  All Types could be queried from the primary UniDOS ROM to get a list of what is available.  Having the 3 means eg: a FatFS could be used with any device handler as the FatFS is only the software layer.  A track disc that supports formatting could work with any formatter software created for UniDOS etc.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 17:46, 28 April 21
@zhulien (https://www.cpcwiki.eu/forum/index.php?action=profile;u=58) That is more or less what SymbOs does, with 3 layers: Main DOS management (public API), FileSystems (Fat, Amsdos, ...), Device drivers.
That's why for instance HxC direct access was so rapidly supported.


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


It's quite disturbing to see the X-Mass active for each floppy access. Makes you wonder if the right drive is selected.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 20:41, 28 April 21
With regard to FatFS... could it be possible to have 3 types of UniDOS nodes [...]
Sure, something in this regard is planned.
At final stage, there will be additional modular items under the DOS node layer itself.

DOS node are the DOS device interface for UniDOS but then...

Some of them will remain stand alone handlers (i.e.: Zero, Albireo SD/UMS, M4).
Some of them will be split in both a device driver and a filesystem (i.e.: X-Mass IDE, HxC Direct)
Some of them will be split in both a device driver and a protocol (i.e.: Albireo serial port, Mini-Booster)


Internally, it is already working this way in FatFs DOS Node. FatFs part (filesystem) is totally independant from X-Mass device driver.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT 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:

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m 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?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m 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 !
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: TotO 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. :)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m 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
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT 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 (https://unidos.cpcscene.net/doku.php?id=fr:manuel#changement_de_repertoire)).
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.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m 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.


Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT 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 (https://unidos.cpcscene.net/doku.php?id=fr:manuel#load_save_sur_des_repertoires)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m 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?



Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m 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?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT 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).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED 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?

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT 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.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 03:59, 04 May 21
What advantages are there for UniDOS over CubeDOS and vice versa?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m 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 (https://www.cpcwiki.eu/forum/index.php?action=profile;u=941) 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).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: TotO on 12:33, 04 May 21
For me, compatibility/reliability is far more important than speed. I have the time on my CPC.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m 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.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT 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)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Ast 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.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m 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.





Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Ast on 17:29, 05 May 21
Everything you detail already exists elsewhere for a while.  ;D
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m 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)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Ast on 17:50, 05 May 21
Just read and try what i wrote in iMPdos post  :P
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED 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.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 20:50, 05 May 21
double post
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 17:36, 07 May 21
You're not really going to use 'fda' as indicator for drive 'a'  ??
You haven't read how smart Unidos is. You can both point an explicit device (ide, fda etc) or a logical drive (a, b) assigned to such a drive.
That allows a lot of softwares to work on mass storage, even when re-initialising ROM 7 and current device, since A: is still pointing to the right drive/directory.
 
Regarding cooperation: you have a point. The thing is everyone has slightly different needs and visions, and it's also too much fun to start from scratch.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 17:21, 08 May 21
I like the way UniDOS is designed with the extension ROMS, i think this will definitely be what makes UniDOS a winner.  It would be great if the other DOS guys worked together though for sure.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 13:01, 09 May 21
Thanks. I will try to keep it as opened and expandable as possible and I hope it will be usefull for current hardwares, but also for upcoming ones.

Anyway, UniDOS 1.11 is now available from https://unidos.cpcscene.net (https://unidos.cpcscene.net) (this is mainly a bugfix release, no new feature yet).

Stay tuned, next release will integrate new features, taking into account various remarks from users and developpers. ;D


About working together, I actually tried to contact some guys who already did some work releated to FAT support, but with no success (I have no problem with that, everyone has its own priorities); so I decided to create a FatFs node on my own because I guess that supporting X-Mass was important.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 12:18, 15 May 21
A preliminary version of the Nova DOS node is now available at https://unidos.cpcscene.net (https://unidos.cpcscene.net).


More info about Nova expansion card:
https://pulkomandy.github.io/shinra.github.io/nova.html (https://pulkomandy.github.io/shinra.github.io/nova.html)


This is a very first version so that X-Mass users can immediatly take advantage of this card because NV-RAM support from FAT32 is a bit slow.
Of course, Albireo users can use it too. They won't notice as much speed boost, but it will safe write accesses to their MicroSD card (it will also consequently make the MicroSD card presence optionnal).
Also, Nova let you use UniDOS without any other additionnal hardware (just limited to floppies and tape).


Final version of Nova will provide a public API so that other programs/ROMs can also use it in a system-friendly manner.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 12:47, 25 May 21
A new version of UniDOS and its Albireo and FatFs DOS nodes is available.


It introduces |LOAD, |SAVE and |SAVEA RSX similar to the ones which can be found in Arnor Ltd. ROMs (Utopia, Maxam).
Theses can be used to manipulate files like original ones, but also directories (which can be used instead of regular LOAD/SAVE in BASIC program if you wish to avoid error management in this peticular use case).


I also enabled the capability to move file from a directory to another using |REN.

Pick this at https://unidos.cpcscene.net (https://unidos.cpcscene.net).

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 11:55, 29 May 21
A patched firmware "u5" for CPC6128 was added to UniDOS website.

It should be useful if you want to use UniDOS in the most compatible manner but cannot install it in ROM slot 7, either because you have the wrong Romboard (such as X-Mem which cannot program slot 7) or because you could not patch your CPC6128 motherboard to disable/change internal ROM 7. Or course, you will need a Romboard which is capable of programming the lower ROM to install this firmware (which X-Mem can). Once this patched firmware "u5" is installed, most softwares which require the DOS to be in ROM slot 7 will work again while UniDOS is in ROM slot 5.

Detailled explanations are available in the installation page of the website, the files are available on the download page (one firmware per keyboard layout).

Please note that 6128plus do not have the ROM 7 issue (internal ROM 7 is auto-disabled when external is installed). You can still use this patched firmware on it if you whish, but you should prefer to directly update ROM 7 if you Romcard can (most can, i.e. FlashGordon or even good old Ramcard can).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: TotO on 13:23, 29 May 21
Nice, because it's not new that CPC 6128 can't replace the ROM7.

Again, it is the DDI task to provide the DOS ROM7 and not a ROM board.
An alternative DOS shouldn't replace it but complement it using ROM6 in example.

If a handful of softwares are incompatible since 30 years, it would be better to patch them.
(rather than drag a problem that has no solution for the next 30 years)

In this way, it is inappropriate to say that you are buying a wrong ROM board if you cannot replace the ROM7.
Especially if this expansion allows you in return to boot with the firmware of your choice and offer 512K of RAM.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 16:51, 29 May 21
Yeah, in a perfect world, softwares would be perfect too.
But there is very little chance that the hundreds of softwares which require DOS in ROM 7 will be patched one day.


That said, maybe "wrong" was not the good wording, "inappropriate" might have been a better choice. :)
And I actually said that updating firmware was made possible by your X-Mem board (it is even mentionned on the website). 8)


So, for the end user which just want the things to work, there are two immediate solutions to get rid of this ROM 7 compatiblity issue:
1. updating ROM 7; which is directly possible on all CPC but the CPC6128 (which has to be fixed).
2. updating firmware ROM; which requires lower ROM compatible Romboard (such as X-Mem).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: TotO on 19:40, 29 May 21
That said, maybe "wrong" was not the good wording, "inappropriate" might have been a better choice. :)
The french version: "si vous avez la mauvaise ROM card (par exemple la X-MEM)", so I suggest that is not an english issue. ;)

The problem with ROM7 is that you can't ask to hundreds of users to hack their CPC 6128, because a compatibility problem may occur with softwares they didn't use. I don't said to patch everything, but the main programs always used today... May be we can list them? Because I have never encounter any problem with games using floppy disc, neither other ROM programs, since I'm using the X-MEM and the X-MASS with AcmeDOS, CubeMDOS or ImpDOS, but problems related to them. ;D

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 20:37, 29 May 21
I applaud TotOffset efforts to provide either:
* A neat solution that requires almost no effort to use old software.
* A neat solution that doesn't require to mod one's CPC.


FWIW, I personally prefer the lower ROM approach, as it allows other very useful features (see thread on this subject), and the Oxford PAO incompatibility doesn't really bother me.
Also, Chany isn't retired yet! When there are no new soft to crack, it can be fun to have old ones to patch.


Wouldn't a perfect world be boring, hence imperfect?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 21:08, 29 May 21
1. updating ROM 7; which is directly possible on all CPC but the CPC6128 (which has to be fixed).
In Germany about 90% of the CPC6128 can replace ROM 7. I don't know much about other regions.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 14:11, 03 June 21
The issue with other implementations of replacement or additional DOS ROMS is the <ROM7 recommendation.  You see, there is only 5 ROMS less than 7 not including ROM 0 and some non-DOS ROMS also require <ROM7.  To allow all the devices to be used at the same time like an installable filesystem, or devicedriver, the extension ROMS of UniDOS make a lot of sense.  But this system could have worked in <ROM7 also as the only additional DOS ROM below 7.  Personally I think it doesn't matter if replacing ROM7 or using <ROM7 as long as it works with the everything I use.  So far there is nothing good - Maxam 1.5 doesn't like M4, Utopia does odd things sometimes, I cannot easily copy things from my USB sticks to my X-MASS and to the M4... it's a crazy world with CPC DOS drivers "for AMSDOS"... and UniDOS is or something that works in a similar way looks to be the only solution.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 19:53, 07 June 21
Yeah, right, way too much incompatibilities. The best thing is to have a monolithic OS.  8) 8) ;) :) :) :)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Audronic on 03:45, 08 June 21
In Germany about 90% of the CPC6128 can replace ROM 7. I don't know much about other regions.

Hi Gunhed
? Does that mean that there are hardware differences in the CPC6128's that will allow rom 7 to be Over Written (X-Mem)
I don't know where to look Does any body Know.
It may be a simple Patch to the Motherboard to allow X-mem to over write rom 7 ?
My Mother boards Z70290 MC0020B don't allow Rom 7 to be Over Written (X-Mem)


Gerald Can you help Please


Keep Safe
Ray
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 04:53, 08 June 21
Hi Gunhed
Does that mean that there are hardware differences in the CPC6128's that will allow rom 7 to be Over Written ...

Exactly, there are different mainboards.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Audronic on 05:24, 08 June 21
Exactly, there are different mainboards.
I was wondering ? Are your CPC6128's That allow rom 7 to be over written identified as Schneider or something else ?
Thanks
KeepSafe
Ray
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: PulkoMandy on 09:44, 08 June 21
It is a very simple modification to add a switch to disable the internal ROM (or even install an alternate one directly inside the CPC).


I don't know about these CPC which could disable the ROM, as far as I know, no one has confirmed (I mean with logic analyzer testing on the ROM pins) if it is really disabled, or if it's active, but the X-Mass ROM is "stronger" and manages to send its own data on the bus (which could work, but is not so nice to the hardware).


If there is indeed a motherboard difference, this should be checked and documented, including the list of motherboard revision numbers where this works or doesn't work. And we can investigate how it was done and where the extra logic is added.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Audronic on 10:29, 08 June 21
Perhaps Pin 42 On the expansion Bus  /ROMEN may be suitable ?
Connected to IC204 Pin 20 /CE


Keep Safe
Ray
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: TotO on 10:52, 08 June 21

It is a very simple modification to add a switch to disable the internal ROM (or even install an alternate one directly inside the CPC).
Or use UniDOS as ROM6 and change nothing. The more "clean hack" is to replace the 6128 internal FDC ROM to have a new DOS.


I don't know about these CPC which could disable the ROM, as far as I know, no one has confirmed (I mean with logic analyzer testing on the ROM pins) if it is really disabled, or if it's active, but the X-Mass ROM is "stronger" and manages to send its own data on the bus (which could work, but is not so nice to the hardware).
I suppose that you want to say he X-MEM, as the X-MASS do not handle ROM. And the X-MEM ROM is automatically disabled when the CPC access the ROM7. In 2013, it was concluded that a bus contention using the Bryce Lower ROM has allowed to disable it on the mainboard MC00020G only. https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/disabling-rom-7/
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: PulkoMandy on 11:25, 08 June 21
I suppose that you want to say he X-MEM, as the X-MASS do not handle ROM. And the X-MEM ROM is automatically disabled when the CPC access the ROM7. In 2013, it was concluded that a bus contention using the Bryce Lower ROM has allowed to disable it on the mainboard MC00020G only. https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/disabling-rom-7/ (https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/disabling-rom-7/)


Yes, I should not post too early in the morning before being fully awake. Sorry for adding even more confusion  :picard:


I meant rather the FlashGordon/MegaFlash or the Ramcard or other expansions that could replace ROM7. On all these interfaces there is a switch to enable or disable the external ROM7 to avoid the conflict with the internal one. But it can still be enabled for Amstrad Plus and "PreASIC" CPC, from what I understand. For the other versions, it seems to work, sometimes, but the hardware was not designed for it and personally I wouldn't recommend using that setup, especially when the mod to cleanly disable the internal ROM is not so hard to do.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: TotO on 12:32, 08 June 21
May be 30 years ago it was funny to read a fanzine and drill holes, cut tracks and solder wires into the CPC, but today?
Especially when the problem came from few old softwares doing direct access to ROM7 and not really from the CPC.

When you add a DDI-1 on the 464, you can't disable the ROM7 too. So, the good way is to replace the ROM IC.
I think that is the same for the 664 and 6128, if you require ParaDOS or UniDOS instead of AmsDOS at ROM7.

Looking the DDI-1/664/6128 FDC schematics, they don't allow to disable the AmsDOS ROM.
I think there are less softwares to patch (or not use) than CPC to hack around the world. ;D

Anyway, ParaDOS works fine at ROM6 for my usage since a decade. Why not UniDOS?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 12:56, 08 June 21
Well, the only important things is that you have plenty of solutions to acheive the compatibility you expect. 8)


1. Basic compatibility: UniDOS in ROM slot <7 and default firmware.
2. Good compatibility: UniDOS in ROM slot 5 and the patched firmware "u5".
3. Better compatibility: UniDOS in ROM slot 7 and default firmware.


Case 1 is possible anycase but won't allow softwares which rely on ROM 7 to be run from UniDOS drives.
Case 2 is possible anycase but requires a X-Mem or M4 Board (for firmware external update).
Case 3 requires a capable CPC; means all CPC where ROM 7 is socketed (DD1, CPC664, fixed CPC6128) or Plus model with a Romboard (any but the X-Mem, as it cannot put ROM 7).


Anyway, ParaDOS works fine at ROM6 for my usage since a decade. Why not UniDOS?
I guess you never tried to launch OCP Art Studio, Oxford PAO, Digitracker... or any cracked game from a ParaDOS floppy.  ;D
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 13:02, 08 June 21
Anyway, UniDOS and the FatFs DOS node where updated.


UniDOS:
FatFs:

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: TotO on 14:51, 08 June 21
The Amstrad Plus provide the Firmware, BASIC and DOS ROM from the cartridge slot, so no problem with the expansion port.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 15:08, 08 June 21
I was wondering ? Are your CPC6128's That allow rom 7 to be over written identified as Schneider or something else ?
All the Schneider CPC6128 I have (5 or 7 or so) can replace ROM 7 (and ROM 0 too). In Germany it's the regular case. Finally I got one CPC6128 (Schneider) which is not capable of ROM 7 replacement. Wow! It was unexpected.

For very long time all this legends of CPCs being incapable of replacing ROM 0 and ROM 7 were just uncertified legends (stories of the crazy), but today I have one of these non working CPCs in my hands - never believed in them before.


But back to topic...
My impression of UniDOS is up to now, that it's a great idea, but not finished yet. I'm looking forward to see the final result. Maybe this idea will work and unify the CPCs mass storage. Let us all hope the best for it.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 09:39, 17 June 21
I think UniDOS has the best compatibility potential with all my hardware without plugging/unplugging all the time.   If a game doesn't work on it, the game can be patched or... perhaps i don't play it, or use another CPC or emulator. 
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 17:03, 18 June 21
Exactly, to omit unplugging/replugging is a big gain!
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 01:36, 09 July 21
A minor update of UniDOS main ROM is available from https://unidos.cpcscene.net (https://unidos.cpcscene.net)


More to follow soon.  ;D