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: HAL6128 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
Quote from: 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?
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
Quote from: 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.

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
|dir,"**/3d*"
work? (:



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

Quote from: HAL 6128 on 20:59, 24 January 21What 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
Quote from: GUNHED on 23:18, 24 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
Quote from: GUNHED on 19:03, 25 January 21Is 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
Quote from: 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

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
Quote from: zhulien on 03:08, 27 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
Quote from: GUNHED on 23:18, 24 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
Quote from: OffseT on 20:01, 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
Quote from: OffseT on 19:51, 29 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
Quote from: zhulien on 13:09, 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
Quote from: zhulien on 13:09, 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 ).

Quote from: roudoudou on 15:02, 30 January 21CPC 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
Quote from: Targhan on 13:15, 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
Quote from: OffseT on 20:16, 06 February 21Do 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
Quote from: Targhan on 21: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 22: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
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: SOS on 08:04, 09 February 21
Quote from: Targhan on 22: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".
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Targhan on 10:25, 09 February 21
Quote from: SOS on 08: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.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: SOS on 10:54, 09 February 21
Quote from: Targhan on 10: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
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
Quote from: OffseT on 11: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, ...
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 13:31, 09 February 21
Quote from: SOS on 13: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)
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
Quote from: m_dr_m on 22: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.

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
Quote from: 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?
Maximum is 4 TB.



Quote from: zhulien on 11: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.
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
Quote from: 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? 

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 01: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.
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
Quote from: zhulien on 02: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 02: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.

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
Quote from: 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.  [...]
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
Quote from: OffseT on 11: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)

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

Quote from: m_dr_m on 12:02, 09 April 21For the other devices, the transfert can be interrupted/resumed? Is there a max time allowed to fetch the data?

Not for now.

Quote from: m_dr_m on 12:02, 09 April 21Another 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
Quote from: 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.
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
Quote from: 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 :) ).
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
Quote from: 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?
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
Quote from: zhulien on 23:08, 22 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
Quote from: OffseT on 10:15, 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
Quote from: GUNHED on 22:03, 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?




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
Quote from: zhulien on 12:38, 26 April 21for 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
Quote from: m_dr_m on 12:34, 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

Quote from: m_dr_m on 12:34, 28 April 21
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)

Quote from: m_dr_m on 12:34, 28 April 21
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).


Quote from: m_dr_m on 12:34, 28 April 21A 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.

Quote from: m_dr_m on 12:34, 28 April 21Also, 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
Quote from: m_dr_m on 12:12, 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
Quote from: zhulien on 16:26, 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
Quote from: m_dr_m on 17:46, 28 April 21
It's quite disturbing to see the X-Mass active for each floppy access. Makes you wonder if the right drive is selected.
I agree. Did you try to remove the X-Mass LED?  :laugh:

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 15:53, 01 May 21
Quote from: m_dr_m on 17:46, 28 April 21@Offset Fair enough! What about doing the switch gymnastic only at drive change?
E.g.:
|A <- Backup Unidos, put Amsdos
cat  <- No NVRAM access
cat  <- No NVRAM access
|B <- Restore Unidos.

E.g.: automatically do |disc before, |dos after?
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
Quote from: m_dr_m on 14:36, 02 May 21
Request:
* |MKDIR alias for save"toto/" which would give back control (if I try to create a directory via save in BASIC, it stops the program)
* |CD alias for load"dir" (same reason + uniformity with other DOS)
|MD and |CD instead. Or |MKDIR and |CHDIR if you like long command. :)
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
Quote from: m_dr_m on 15:53, 01 May 21
E.g.: automatically do |disc before, |dos after?
This is actually equivalent to what's done everytime a CAS_* that needs to be redirected to the AMSDOS/ParaDOS call is done.

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

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

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

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

Quote from: m_dr_m on 14:57, 02 May 21Good point, I like uniformity too. Yet I also enjoy Morse entropy principle: * Frequent commands should be short * Less frequent commands can be long Plus: * Modifying commands should be explicit
Both short and long/explicit syntaxes could exist. No reason to keep only a cryptic form just because it is of a frequent usage.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 10:19, 03 May 21
Quote from: OffseT on 01:34, 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
Quote from: m_dr_m on 10:19, 03 May 21
Wat? It also stops the program on success, which is not consistent with load/save for binaries.
Details here: LOAD/SAVE sur des répertoires (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
Quote from: OffseT on 01:34, 03 May 21This is actually equivalent to what's done everytime a CAS_* that needs to be redirected to the AMSDOS/ParaDOS call is done.
Yep that exactly the problem! For Orgams that's every 2kb, for Starkos it would be every byte (one hour to load?).

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



Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 13:29, 03 May 21
Quote from: OffseT on 01:34, 03 May 21At the end, the best solution will be to actually create a full featured "Floppy DOS Node" that will override the internal DFA/DFB drives (btw, overriding is already working).
Wouldn't this node need the same buffers than AMSDOS, so we would RUN into the same issue?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 14:13, 03 May 21
Quote from: m_dr_m on 13:27, 03 May 21Yep that exactly the problem! For Orgams that's every 2kb, for Starkos it would be every byte (one hour to load?).
I though about that, but that's very rare. Even copiers bufferize.
That brings us back to the general principle: common use cases shouldn't be penalised to deal with rare cases.
You still have the control over CAS_ routines, no?
So 'sitting' in |DISC mode while just one file is opened wouldn't be so complex, would it?
AMSDOS/ParaDOS wrapping is not required between every 2K buffers of ASCII files.

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

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



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

This DOS node could comply with UniDOS memory management, and if required, it could handle additional memory in a system-friendly manner (like FatFs does).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 19:01, 03 May 21
Quote from: OffseT on 14:13, 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
Quote from: GUNHED on 19:01, 03 May 21
Where do you have nvRAM in the X-MASS?
How to access it?
It is emulated either thru a file on the file system (default mode) or by using some raw sectors (fatfs.cache.on mode) which are located between the partition table and the first partition.
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.


Quote from: 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.

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
Quote from: 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.


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
Quote from: GUNHED on 20:50, 05 May 21You'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
Quote from: OffseT on 16:51, 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
Quote from: OffseT on 16:51, 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
Quote from: GUNHED on 21:08, 29 May 21In 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
Quote from: Audronic on 03:45, 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
Quote from: GUNHED on 04:53, 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

Quote from: 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).
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.


Quote from: PulkoMandy on 09:44, 08 June 21I 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
Quote from: TotO on 10:52, 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).


Quote from: TotO on 12:32, 08 June 21Anyway, 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
Quote from: Audronic on 05:24, 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
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 12:17, 09 August 21
A very first version on the DOS node for the M4 Board is now available. 8)

It does not have all the planned features yet, but it is fully fonctionnal and let you use the M4 Board integrated with any other card supported by UniDOS while ensuring AMSDOS compatibility.

Big thanks to Chany who provided me with his M4 Board. :-*

Main features are:
Please refer to UniDOS website for installation and usage instructions.


-> https://unidos.cpcscene.net (https://unidos.cpcscene.net) <-
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Targhan on 15:28, 09 August 21
Excellent news! I will test this on my return from holidays. Well done and thanks for your work!!
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 16:46, 09 August 21
Hello UniDOS team. Well, I don't know who to ask in particular, so I ask here...

As I heart, the UniDOS does use (without the Albireo) the Nova card for storage of some data. Can you please tell me in which way? Is some kind of directory structure used?

The reason I ask, is to eventually have something (data structure, code, etc.) which is compatible with every application we use/create.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 14:29, 10 August 21
UniDOS itself does not rely on Nova card, it is totally independent from any additional hardware.


Only Nova and FatFs DOS nodes are making use of the Nova card.
Both are only using the last 8K memory page of the Nova card (the one which embeds clock registers).


Further UniDOS nodes that might make use of the Nova card will also only use this last 8K page.


It means that all other memory pages are available for non-UniDOS related applications.
A nv-ram library is still on the todolist so that several applications could use it at the same time.
Anyway, it is not a priority for now since I have so many other things to release before.

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 15:34, 11 August 21
Quote from: OffseT on 14:29, 10 August 21
Only Nova and FatFs DOS nodes are making use of the Nova card.
Both are only using the last 8K memory page of the Nova card (the one which embeds clock registers).
Thanks, so page four of the Nova is completely used for the FAT FS, means we need nvRAM management only for Nova pages 1-3.
Thanks for your information, this helps.  :)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 14:45, 21 August 21
UniDOS 1.34 is available. 8)

This is a minor release which is fixing error handling in a very special case which is not reachable with the currently released DOS nodes.

Here is a short video about current nodes status:
http://amsnet.chez.com (http://amsnet.chez.com)

Built-in floppies & tape, Albireo (SD+USB), X-Mass (IDE), Nova, and M4 Board (SD+DSK) at the same time. ;D
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: roudoudou on 17:51, 21 August 21
"the publisher has marked video as private"
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 18:22, 21 August 21
Quote from: roudoudou on 17:51, 21 August 21
"the publisher has marked video as private"


Ok, thx. Moved to another place.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 16:13, 06 September 21
UniDOS 1.35 was released. 8)

It fixes a few rare but annoying issues.

Get it here: https://translate.google.com/translate?sl=fr&tl=en&u=https://unidos.cpcscene.net
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 14:58, 08 September 21
Quote from: OffseT on 16:13, 06 September 21
UniDOS 1.35 was released. 8)

It fixes a few rare but annoying issues.

Get it here: https://translate.google.com/translate?sl=fr&tl=en&u=https://unidos.cpcscene.net


The download links didn't work for me.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 15:49, 08 September 21
Quote from: zhulien on 14:58, 08 September 21
The download links didn't work for me.


Hum... Strange, it is just a Google Translate shortcut.
Get it directly from https://unidos.cpcscene.net/doku.php?id=fr:telechargements if Google don't like you. :)

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: ComSoft6128 on 16:32, 08 September 21
I'd like to buy this on cartridge for a 6128 Plus, can anyone provide one?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 02:28, 09 September 21
Quote from: ComSoft6128 on 16:32, 08 September 21
I'd like to buy this on cartridge for a 6128 Plus, can anyone provide one?


Actually would it be possible to make a multi-slot ROM board for this on plus machines just ROM 7 + 33, 34, 35... with inbuilt NovaRAM on a single cart?  (but still compatible with other ROM boards)?

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 11:13, 09 September 21
Quote from: ComSoft6128 on 16:32, 08 September 21
I'd like to buy this on cartridge for a 6128 Plus, can anyone provide one?
It would need some additional work to make it possible.

Not only because of the physical cartridge creation, but also because UniDOS needs to be put in a cartridge together with DOS nodes, which is not possible currently. That said, it is feasible. At least, a CPR with a special firmware could do the job, but if you want a physical cartridge, you'll still need to find someone to assemble it.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 11:17, 09 September 21
Quote from: zhulien on 02:28, 09 September 21

Actually would it be possible to make a multi-slot ROM board for this on plus machines just ROM 7 + 33, 34, 35... with inbuilt NovaRAM on a single cart?  (but still compatible with other ROM boards)?
Cartridges provide limited ROM paging and do not have write capability. So, some tricks would be required (modified firmware, special read sequences to simulate write into built-in Nova RAM, ...). Not that easy.

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 19:38, 11 September 21
A small update of the FatFs DOS node was released today.
It improves a bit built-in Nova support and fixes some internals to be more system compliant regarding interrupts and ROM management.


Get it there: https://unidos.cpcscene.net/doku.php?id=fr:telechargements

Help is still wanted to provide this FatFs DOS node the love it would need to reach the performance of Albireo and M4 nodes.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 11:53, 19 September 21
UniDOS web site and its full documentation was translated to English. 8)
It was quite a hard work, but it will be more convinient than using Google translate. :P
There might still be some typos, let me know and I will fix them.



The web site should auto detect your language when accessing
https://unidos.cpcscene.net (https://unidos.cpcscene.net)


Anyway, you can still select your preferred language from the header bar.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 17:50, 19 September 21
Quote from: ComSoft6128 on 16:32, 08 September 21
I'd like to buy this on cartridge for a 6128 Plus, can anyone provide one?
I just made a small tool to create custom Amstrad Plus cartridges with UniDOS installed.

It can also be used to install additional tool ROMs (such as Protext, Utopia, Maxam...).
Most ROMs will work, with the notable exception of Orgams which is doing some direct hardware access (it should be easy to adapt it anyway).
Up to 30 ROMs can be programmed in the cartridge.

It might be useful for users owning a C4CPC with an Albireo (or a X-Mass) but with no ROM board to install UniDOS ROMs.

You can use the application menu to automatically download the latest UniDOS ROMs from the official web site.

Pick it at http://amsnet.chez.com
AmigaOS and MorphOS versions will also pop on Aminet tomorrow.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: ComSoft6128 on 18:06, 19 September 21
 :) Appreciated :)


Now can someone make this for me - say for £30 + postage.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 13:42, 20 September 21
So, what is the difference with makecart tool http://www.cpcwiki.eu/forum/applications/makecart/ from @arnoldemu (https://www.cpcwiki.eu/forum/index.php?action=profile;u=122) ?
Asking for a friend.



Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 13:51, 20 September 21
Quote from: OffseT on 17:50, 19 September 21Most ROMs will work, with the notable exception of Orgams which is doing some direct hardware access (it should be easy to adapt it anyway).
Yep. Hardware access is needed because the debugger works firmware-free (to be able to debug code in e.g. &b000 while remaining fast).
The cross-rom call routines are a bit of a mess: there are several of them with slightly different API adapted to each client's need at the time.
I started to try to factorise that, but it just added yet another way of doing it!

So, a complete clean-up could take this special firmware vs hardware dichotomy into account.
NB: orgams roms are detected at first invocation, and then stored persistently.
So I guess we would just have to store 2 sets of ids instead: firmware and hardware.

If anyone is interested with helping with that, I can give all the necessary pointers!
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 15:18, 20 September 21
Quote from: m_dr_m on 13:42, 20 September 21
So, what is the difference with makecart tool http://www.cpcwiki.eu/forum/applications/makecart/ (http://www.cpcwiki.eu/forum/applications/makecart/) from @arnoldemu (https://www.cpcwiki.eu/forum/index.php?action=profile;u=122) ?
Asking for a friend.
I didn't know about this tool before you told me about.

I guess it is quite similar, probably the same kind of firmware patch too.
Maybe the main difference is that UniDOS Cartridge Creator handles more ROMs; it also takes care about Burnin' Rubber when original Plus AMSDOS is chosen... and obviously it has a GUI.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Maniac on 01:02, 22 September 21
Finally got around to trying this out now that M4 support is available. This is a brilliant development but I think I've found a bug even if it might be unique to my setup.


My setup is a 6128 Plus with a C4CPC cartridge, an X-Mem (with ROMboard element disabled) and an M4 Board. I'm using the M4 board for the ROMs as shown in the screenshot where UniDOS is in slot 7.


The C4CPC is running the original Plus cartridge image with no other ROMs present.


When I have all of this connected the system runs fine for the most part until I run the command ¦drive on its own. When I do this the command lists the Available DOS devices and Logical drives and then the system crashes with vertical lines down the screen. Reset try again and it happens every time.


If I switch my cartridge to the original physical system cart (i.e. not the C4CPC) then it all works without issue. So I thought it was (and most likely is) a conflict between the various devices providing ROMs. However I then switched back to the C4CPC and used the Firmware 3.16 cartridge image and it works but I have no access to the disc drive just the M4. So I created a custom cartridge image using the new tool you made to do this with the ROMs in the same slots as the screenshot above and removed the ROMs from the M4 slots and I still get the same issue with a system crash.


To test further I then switched the ROMs about on the M4 as shown in the screenshot with UniDOS in slot 6.


Thought I'd cracked it as the ¦drive command worked initially but now crashes consistently again.


Everything else works that I've tried but this I'm afraid.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Cwiiis on 03:09, 22 September 21
Quote from: Maniac on 01:02, 22 September 21
Finally got around to trying this out now that M4 support is available. This is a brilliant development but I think I've found a bug even if it might be unique to my setup.


My setup is a 6128 Plus with a C4CPC cartridge, an X-Mem (with ROMboard element disabled) and an M4 Board. I'm using the M4 board for the ROMs as shown in the screenshot where UniDOS is in slot 7.


The C4CPC is running the original Plus cartridge image with no other ROMs present.


When I have all of this connected the system runs fine for the most part until I run the command ¦drive on its own. When I do this the command lists the Available DOS devices and Logical drives and then the system crashes with vertical lines down the screen. Reset try again and it happens every time.


If I switch my cartridge to the original physical system cart (i.e. not the C4CPC) then it all works without issue. So I thought it was (and most likely is) a conflict between the various devices providing ROMs. However I then switched back to the C4CPC and used the Firmware 3.16 cartridge image and it works but I have no access to the disc drive just the M4. So I created a custom cartridge image using the new tool you made to do this with the ROMs in the same slots as the screenshot above and removed the ROMs from the M4 slots and I still get the same issue with a system crash.


To test further I then switched the ROMs about on the M4 as shown in the screenshot with UniDOS in slot 6.


Thought I'd cracked it as the ¦drive command worked initially but now crashes consistently again.


Everything else works that I've tried but this I'm afraid.
I see similar things with just the X-Mem on a Plus and I think it's actually power related - I see it more easily if I use a separate power adapter rather than the monitor which leads me to think it's a voltage drop caused by the extra power draw of the X-Mem and C4CPC combined. I have an MX4 on the way which I'll configure with external power to see if it affects things.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Maniac on 10:13, 22 September 21
Quote from: Cwiiis on 03:09, 22 September 21
I see similar things with just the X-Mem on a Plus and I think it's actually power related - I see it more easily if I use a separate power adapter rather than the monitor which leads me to think it's a voltage drop caused by the extra power draw of the X-Mem and C4CPC combined. I have an MX4 on the way which I'll configure with external power to see if it affects things.


Good to hear that I'm not the only one. I might disconnect the internal drive and just use my externally powered HxC to see if it still happens.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 13:49, 22 September 21
Quote from: Maniac on 10:13, 22 September 21
Good to hear that I'm not the only one. I might disconnect the internal drive and just use my externally powered HxC to see if it still happens.
That's interesting.
So, I just did some tests and I it actually appears to be some power drain issue.

Here is my base config (which is quite stable as I am using it everyday):
6128plus + Mulfiface Two + Albireo + MegaFlashGordon + Nova + dual floppies (both powered by the monitor)

What I experimented:
Base config + C4CPC -> still perfectly stable.
Base config + M4 Board -> still perfectly stable, but I can notice that the blue led of the board is slighlty blinking when floppies are being used.
Base config + X-Mem -> still perfectly stable.
Base config + C4CPC + M4 Board -> don't even boot, at best it crashes during firmware start, most of the time even before.
Base config + C4CPC + X-Mem -> don't even boot, at best it crashes during firmware start, most of the time even before.

I also tried with an USB stick plugged on the Albireo: no changes; when it is stable, plugging a USB stick won't make the system unstable.
Please also note that I am not using the Mother-X4 which is known to have issues regarding 5V power drain when no external power is used.

Then I also tested with an Amiga external power supply able to deliver 5A:
Base config + C4CPC -> perfectly stable.
Base config + M4 Board -> perfectly stable, blue led not blinking anymore.
Base config + X-Mem -> perfectly stable.
Base config + C4CPC  + M4 Board -> booted once, but crashed after a while when doing nothing.
Base config + C4CPC  + X-Mem -> don't even boot.

All of this make me think that the issue is not only related to the power supply itself but also to the way the motherboard is designed to deliver the 5V to all the components. I guess we are reaching some limits of what can be plugged together on a Plus.
I'm afraid you will have to choose between M4 Board and C4CPC.

About |DRIVE, since it is accessing all the devices together, it makes sense that it could triggers easily the power issue in your case.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 18:32, 22 September 21
Ok, I did an additional test case which is interesting too.

6128plus
+ Mulfiface Two
+ Albireo
+ MegaFlashGordon
+ Nova
+ dual floppies (both powered by the CPC)
+ X-Mem (ROMs disabled)
+ M4 Board

And it works perfectly!

With the original 5V from the monitor I still have the blue led of the M4 slightly blinking, but it seems not to affect operations.
With the 5V/5A power supply all is fine.

It means that when no C4CPC is attached, I can really plug many stuff together with no issue.
So the final conclusion might be that C4CPC is draining too much power from the cartridge port, which is preventing other peripherals from the expansion port to operate.

That said, this configuration seems to be the absolute maximum with single power supply from the CPC (for instance, adding a Mini-Booster creates instabilities and random crashes).
It means that adding even more expansion cards will require the Mother X4 with the additional external power supply plugged, which will also fixes the C4CPC issue draining power from cartridge (I just tested this last case here, all together, no issue).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Maniac on 20:22, 22 September 21
Thanks @OffseT (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1826) for all of that testing. That makes for interesting reading and I at least know it's not just me. With cartridge image support now available in the M4 I could switch to just using the original system cartridge and use the C4CPC where that doesn't work.


On a different topic; will long file name support be coming to the M4 node please? Or is this something that could be added to the main UniDOS ROM in the future please?


Sorry if this is covered in the documentation but I've not found reference to it yet.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 16:01, 23 September 21
Quote from: Maniac on 20:22, 22 September 21
[...]  will long file name support be coming to the M4 node please? Or is this something that could be added to the main UniDOS ROM in the future please?

M4 node does already support long file names for the Library, because it hosts alien files (DSK, SNA, CPR coming from emulators) for which it is helpful to handle long file names.

Regarding global long file name support, as you guessed, it should be left to the responsability of UniDOS itself, not the DOS nodes (just like it is already the case for the symbolic links).
Long file name support shall be added in a universal way, including devices not supporting long file names on their own (such as AMSDOS floppy discs).
One of the features of UniDOS is that it actually ensures strong compatibility between devices, so that what you store on SD card of Albireo will work the same from floppies or IDE hard disk, and long file names shall not break this behavior.

That said, apart some rare softwares, long file names are not supported on CPC.
So it makes very little benefits and therefore it is a low prority feature in my todo list.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: gerald on 20:39, 23 September 21
Quote from: OffseT on 13:49, 22 September 21
That's interesting.
So, I just did some tests and I it actually appears to be some power drain issue.

Here is my base config (which is quite stable as I am using it everyday):
6128plus + Mulfiface Two + Albireo + MegaFlashGordon + Nova + dual floppies (both powered by the monitor)

What I experimented:
Base config + C4CPC -> still perfectly stable.
Base config + M4 Board -> still perfectly stable, but I can notice that the blue led of the board is slighlty blinking when floppies are being used.
Base config + X-Mem -> still perfectly stable.
Base config + C4CPC + M4 Board -> don't even boot, at best it crashes during firmware start, most of the time even before.
Base config + C4CPC + X-Mem -> don't even boot, at best it crashes during firmware start, most of the time even before.

I also tried with an USB stick plugged on the Albireo: no changes; when it is stable, plugging a USB stick won't make the system unstable.
Please also note that I am not using the Mother-X4 which is known to have issues regarding 5V power drain when no external power is used.

Then I also tested with an Amiga external power supply able to deliver 5A:
Base config + C4CPC -> perfectly stable.
Base config + M4 Board -> perfectly stable, blue led not blinking anymore.
Base config + X-Mem -> perfectly stable.
Base config + C4CPC  + M4 Board -> booted once, but crashed after a while when doing nothing.
Base config + C4CPC  + X-Mem -> don't even boot.

All of this make me think that the issue is not only related to the power supply itself but also to the way the motherboard is designed to deliver the 5V to all the components. I guess we are reaching some limits of what can be plugged together on a Plus.
I'm afraid you will have to choose between M4 Board and C4CPC.

About |DRIVE, since it is accessing all the devices together, it makes sense that it could triggers easily the power issue in your case.

What is your configuration regarding the M4 or XMEM ?
If you enable a lower ROM on these, you will have some trouble for sure as the C4CPC will not be able to control CPC boot.
It will load the cartridge while the lower ROM (one the M4 or XMEM) will run and possibly try to access it during its init process.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 20:47, 23 September 21
Quote from: gerald on 20:39, 23 September 21What is your configuration regarding the M4 or XMEM ? If you enable a lower ROM on these, you will have some trouble for sure as the C4CPC will not be able to control CPC boot. It will load the cartridge while the lower ROM (one the M4 or XMEM) will run and possibly try to access it during its init process.

Nope, ROMs were totally disabled on both M4 and X-Mem (I only use ROMs from the MegaFlashGordon).

It really looks like a power drain issue, but well, I really had to plug many many things together before it happens.
I have absolutely no issues in normal usage (Dual drives + C4CPC + Multiface Two + Albireo + Nova + MegaFlashGordon).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: gerald on 21:32, 23 September 21
The C4CPC consume about 70mA more than the original eprom and is using a 3.3V local voltage regulator.
It would require quite a big voltage drop to prevent the regulator to properly work (it need at less 3.7V).
Also, on one of my plus, I measured the path from the power switch to the cartridge : 0.17ohm + 0.03ohm on the ground at the power plug, so a voltage drop of less than 20mV from plug to cartridge.

Other option are possible :
- power switch is not that clean, and then we can have voltage drop that can affect the whole system. But then accessing a drive (real one) would cash the system too.
- load on bus such that some signal do not behave properly anymore.
- ...

I do not have any issue with the C4CPC + XMEM combo. Need to find time to test the M4.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 21:53, 23 September 21
The initial related issue from Maniac is a crash which occurs during the UniDOS |DRIVE RSX, which is actually accessing all devices (including disc drives) in a row.
Drive motor should be considered as an issue trigger.

Regarding X-Mem, as I said, I have no issue either with it unless I add numerous other interfaces.
Maniac instabilities might be easier to trigger because of an aging power supply.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 01:11, 24 September 21
By the way, UniDOS 1.36 was released.

As always: https://unidos.cpcscene.net (https://unidos.cpcscene.net)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Cwiiis on 11:40, 24 September 21
Quote from: gerald on 21:32, 23 September 21
The C4CPC consume about 70mA more than the original eprom and is using a 3.3V local voltage regulator.
It would require quite a big voltage drop to prevent the regulator to properly work (it need at less 3.7V).
Also, on one of my plus, I measured the path from the power switch to the cartridge : 0.17ohm + 0.03ohm on the ground at the power plug, so a voltage drop of less than 20mV from plug to cartridge.

Other option are possible :
- power switch is not that clean, and then we can have voltage drop that can affect the whole system. But then accessing a drive (real one) would cash the system too.
- load on bus such that some signal do not behave properly anymore.
- ...

I do not have any issue with the C4CPC + XMEM combo. Need to find time to test the M4.

The one thing that really triggers the situation for me is Pinball Dreams. Some of the display will be incorrect and it crashes intermittently if I play it with both C4CPC and X-MEM connected on a 6128 Plus. Orgams also intermittently resets during scrolling with this configuration, but that's less consistent. I've cleaned the power socket (which did help, so I guess it's marginal), not tried cleaning the switch yet, but it's quite a different mechanism to the standard CPC, it looks unlikely to help...
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Maniac on 16:47, 24 September 21
Quote from: OffseT on 21:53, 23 September 21
The initial related issue from Maniac is a crash which occurs during the UniDOS |DRIVE RSX, which is actually accessing all devices (including disc drives) in a row.
Drive motor should be considered as an issue trigger.

Regarding X-Mem, as I said, I have no issue either with it unless I add numerous other interfaces.
Maniac instabilities might be easier to trigger because of an aging power supply.
I've now managed to do a bit more testing with combinations of peripheral connected. One thing I also forgot to mention before was that I power my M4 board via the USB socket on the board so power is not coming from my 6128 plus for that. I also don't power the MX4. These are my findings:
This is similiar to a situation I found before when I first got my C4CPC. In the end from discussions on this forum the conclusion was that this was down to devices fighting for priority with regard to ROMs - https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/amstrad-cpc-wifi/msg128379/#msg128379 (https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/amstrad-cpc-wifi/msg128379/#msg128379)


So all is now good with everything connected. Thank you for everyones help with this. Hope this post helps others too.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Maniac on 17:04, 24 September 21
Think I spoke too soon! Upgraded to v1.36 of UniDOS and got back to a similar position although the crashes don't happen quite so frequently.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 19:55, 24 September 21
Quote from: Maniac on 17:04, 24 September 21
Think I spoke too soon! Upgraded to v1.36 of UniDOS and got back to a similar position although the crashes don't happen quite so frequently.
Well, this should be nothing related. v1.36 has absolutely no changes related to this.


Regarding additional information you provided I did further tests and I guess that I could reproduce exactly your issue.
My base config is the same as previous: Multiface Two + Albireo + Nova + MegaFlashGordon (my ROMs 0-31 are set in it, ROMs are disabled in X-Mem and set to slots 32-63 in M4).

Case 1:
Base config + M4 Board + X-Mem + System cartrige
|DRIVE never crashes.

Case 2:
Base config + M4 Board + X-Mem + C4CPC (set to start with system cartridge)
|DRIVE leads to a crash from time to time (filling the screen and all memory with &00,&3c,&00,&3a).


Weird.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Maniac on 20:57, 24 September 21
Quote from: OffseT on 19:55, 24 September 21
Case 1:
Base config + M4 Board + X-Mem + System cartrige
|DRIVE never crashes.

Case 2:
Base config + M4 Board + X-Mem + C4CPC (set to start with system cartridge)

|DRIVE leads to a crash from time to time (filling the screen and all memory with &00,&3c,&00,&3a).


Weird.
Yes, that exactly mirrors what I see. I agree it's pretty odd behaviour.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 18:57, 08 October 21
I'm a couple of weeks behind Maniac as I recently got my Nova cards and the M4 support is what I also was waiting for.  Definitely the most useful DOS software since all the cool hardware came out.


First Setup:


6128Plus + M4 Board + X-Mem (ROMs disabled) + System cartridge (with Parados) + Zaxon USB 3" Floppy Replacement + X-Mass

Symbiface 2 is listed as compatible, is that using the same driver as X-Mass?  Is Symbiface 3 supported yet or would that need a different driver?


If UniDOS is in ROM7, will CP/M still work?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 20:11, 08 October 21
I just installed all the examples as per the UniDOS page with the latest downloads, but get FATFS wrong install, M4 wrong config, then I cannot type on the keyboard

ROMS as follows: Any ideas?  I have tried removing all ROMS that weren't downloaded from UniDOS (DISCO6, SUPER, PROTEXT, MAXAM) and same thing happens.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 20:41, 08 October 21
1/ Are you sure you can replace your ROM 7? (It doesn't work with unmodified CPC 6128)
2/ I though M4 was meant to be as ROM 6, but I might be wrong.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 20:53, 08 October 21
Quote from: m_dr_m on 20:41, 08 October 21
1/ Are you sure you can replace your ROM 7? (It doesn't work with unmodified CPC 6128)


I am using a 6128 Plus.  Is that able to have ROM 7 replaced?  Note: I have now verified it works in slot 7.



Quote from: m_dr_m on 20:41, 08 October 21
2/ I though M4 was meant to be as ROM 6, but I might be wrong.


I have reassigned the M4 ROM to slot 127 as suggested.


The other thing I was thinking after reading the documentation in more detail, it says the filesystem is compatible with normal AMSDOS, does that mean M4 must now be 8 letter filenames in uppercase?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 21:01, 08 October 21
I disabled the M4 rom (which usually is in slot 6) and now keyboard works and unidos appears to work - only a FATFS error.


It makes sense we are using a replacement M4, but do we need the old M4?  Autoexec.bas seems to no longer run.


"Moreover, you will also have to take care of the M4 Board configuration; in order to avoid conflicts, the M4 Board built-in ROM must be moved to a slot greater than 16 so that it is no longer initialized by the system (but it will still be used internally by UniDOS)."



If i turn off FATFS, I can use the SDCARD in the M4 by LOAD"SD:"



The documentation does say that the assignments are persistent but so far for me they reset every reboot.  Also I am unsure if the NOVA is actually doing anything, is there a way to tell?

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 21:27, 08 October 21
M4 node is not a replacement for the M4 ROM. It uses the M4 ROM input area internally (M4 Board works this way, not with regular input ports).


The error "M4 Board wrong config!" means that you missed the point were the M4 ROM shall be moved to a slot greated than 15 (127 is suggested, see screen grab in documentation), so that it is made invisible to the system (otherwise its DOS/RSX section would conflict with UniDOS).


CP/M will still work if you keep the AMSDOS ROM in addition to UniDOS (and UniDOS will use it to handle floppies).


Regarding FatFs error you have, I need to check what could happen in your case.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 21:31, 08 October 21
Quote from: zhulien on 21:01, 08 October 21
The documentation does say that the assignments are persistent but so far for me they reset every reboot.  Also I am unsure if the NOVA is actually doing anything, is there a way to tell?
They are permanent. 8)
... unless you hear a beep, which means it was reset (usually because of ROMs being moved, can also happen in case another ROM trashed everything, or of course when you press CONTROL during boot).


|NODE will mark the Nova node with a "!" if it is in use.




Hmm, also, when an error is displayed, the keyboard should not be locked at all, which makes me think there is something weird with FatFs in your case. :P
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 21:40, 08 October 21
Quote from: zhulien on 18:57, 08 October 21
Symbiface 2 is listed as compatible, is that using the same driver as X-Mass?  Is Symbiface 3 supported yet or would that need a different driver?


Symbiface 2 and X-Mass are the same regarding IDE.
Symbiface 3 will need an additionnal node (but don't count on me for this one ::) )
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 21:47, 08 October 21
If I remove the FATFS, the M4 node works fine (with the original M4 ROM at 127).  I am guessing it works fine.


Reset with control does a node / device scan i guess...


Afterwards it is fast.  But no M4 by default (every time)


I need to:


|DOS (to enable UniDOS)
|DRIVE (shows only 4 physical devices, FDA, FDB, M4 and ZERO)
LOAD "M4:" (which will assign M4 to both |a and |b)
CAT (lists the content of the SDCARD root)


RESET, or POWER off will lose the assignment of M4 to |a & |b



Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 21:49, 08 October 21
Quote from: OffseT on 21:31, 08 October 21
|NODE will mark the Nova node with a "!" if it is in use.


I have verified the ! against the Nova node.


No beep when restarting and losing assignments.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 21:51, 08 October 21
X-MASS has a 512MB DOM in it, is that an issue for the FATFS node?


Current config as:  Only FATFS-1.22 I need to remove to allow the system to work at all.


I have no file !UNIDOS!.NVM in the root of my sdcard.


Is there a certain order that physical devices need to be plugged in?  Or is there an order of nodes which causes one to be used before another?  Such as X-MASS, M4 and NOVA all support non volatile RAM.


My devices physically are:


from near the CPC to far: M4, X-Mem, Y-Mem, X-Mass, Nova.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 22:08, 08 October 21
Interesting... I removed the Nova and now FATFS works and the X-MASS was scanned with physical devices shown


AND...


The Assignments now remember after a reset.  (and yes, i tried the 2 Novas, same behaviour)


At a glance, is it trying to read from one, but write to the wrong?  Or do all devices usually get written to so they are all in sync? regarding the NVRAM.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 22:12, 08 October 21
Just formatted my IDE and got 499MB free, now all seems to work flawlessly as per docs... (except the Nova)... I guess with SDCard + X-MEM no real need for NOVA?  But I guess the behaviour is nice to know.


Currently there are no HXC nodes right?  To use the USB as a native USB stick - as per Symbos?  Then we can have 3 mass storage devices on line, 4 if adding 2 HXC devices at once - not including Albireo (which I don't have yet).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 23:28, 08 October 21
Was supposed to be an early night and i am still up at 7:30am... i got carried away, UniDOS is FANTASTIC!!!


I really hope i can now continue and make some dos node too.


I couldn't however change into any DSK files, always mount failed.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 10:54, 09 October 21
Thx for the additional information, I better understand your issue now.
It looks like something is preventing your Nova cards from properly working.

It explains all your issues:

I was reported once a similar issue by Chany/NPS.
He used a MotherX4 with X-Mass, X-Mem and Nova, and it did not work.

I don't know what is the actual issue, but he could fix it by plugging the Nova directly to the CPC, using the MotherX4 only for X-Mem and X-Mass.
Maybe using auxiliairy MotherX4 power supply could also fix your issue.

Cards order or ribbon cable length should not be an issue.
On my 6128plus I have a 50cm ribbon cable with Multiface Two, MegaFlashGordon, Albireo and Nova on it, and it works perfeclty (moreover, Nova is at the end of the cable).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 11:00, 09 October 21
Quote from: zhulien on 23:28, 08 October 21
I couldn't however change into any DSK files, always mount failed.
Which error is reported?
Are your files actually detected as DSK files? (you can see it by using, using |LIBRARY)
Also, only unzipped DSK from the Library are supported.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 11:07, 09 October 21
Quote from: zhulien on 22:12, 08 October 21
[...] no real need for NOVA?
In your case, the advantage of the Nova is that FatFs won't use the main memory, which gives a much better compatilibty with old softwares.

Quote from: zhulien on 22:12, 08 October 21
Currently there are no HXC nodes right?  To use the USB as a native USB stick - as per Symbos?  Then we can have 3 mass storage devices on line, 4 if adding 2 HXC devices at once - not including Albireo (which I don't have yet).

Sure, HxC direct mode support (as well as MS-DOS floppies) is in the todolist of the FatFs node, but my time is limted. :P
In fact, FatFs node should be able to support all FAT-based devices.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 15:37, 09 October 21
Quote from: OffseT on 10:54, 09 October 21
Maybe using auxiliairy MotherX4 power supply could also fix your issue.


I was wondering that too, I will give it a try and let you know the outcome.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 15:42, 09 October 21
Quote from: OffseT on 11:00, 09 October 21
Which error is reported?
Are your files actually detected as DSK files? (you can see it by using, using |LIBRARY)
Also, only unzipped DSK from the Library are supported.


Only 'Mount failed', no more info.  The DSK images are not zipped or compressed.  I was thinking initially i got the syntax wrong, still not totally sure.  They do work with the standard M4 ROM.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 17:52, 09 October 21
Quote from: zhulien on 15:42, 09 October 21
Only 'Mount failed', no more info.  The DSK images are not zipped or compressed.  I was thinking initially i got the syntax wrong, still not totally sure.  They do work with the standard M4 ROM.
There is very little chance that a DSK could work with M4 default ROM and not with UniDOS, it uses the same M4 Board feature internally.

You may use a wrong syntax.
Are your DSK properly listed by |LIBRARY?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 18:23, 10 October 21
|library doesn't list anything
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 18:35, 10 October 21
Quote from: zhulien on 18:23, 10 October 21
|library doesn't list anything
You need to put files in your M4 Library to be able to use them with |DSK, |SNA or |CPR.
As explained in the documentation, the goal of the M4 Library is to store aliens files (aka files which are not CPC files but rather files from emulators).

And for a better handling of the files, the Library supports long file names as well as directories.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 07:41, 11 October 21
thanks, I will try that.  I actually wondered what the library folder was for, my my mind I was thinking that when I opened a library, it used that folder as a scratch area of some type. thanks
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 10:32, 11 October 21
Quote from: zhulien on 07:41, 11 October 21
thanks, I will try that.  I actually wondered what the library folder was for, my my mind I was thinking that when I opened a library, it used that folder as a scratch area of some type. thanks
M4 Library handling is explained within the M4 DOS node documentation: The Library (https://unidos.cpcscene.net/doku.php?id=en:manuel_n%C5%93uds#the_library)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 19:37, 13 October 21
What is your thoughts on introducing a |c which can be assigned to any logical device?  I suspect it would be a lot less compatible than |a and |b?  But... some devices ROMs for example RAM drives historically had |c or |m.  Going further if |c could work reasonable well for most things, what about adding another bunch... or will it take away standard CPC RAM for the RSX registrations?


The reasons as follows.  The logical to physical behaviour works really really good in UniDOS, but 2 drives can be a bit of a pain if you only temporarily want to check the contents of somewhere (as an example) but continue your main work from one location, and play around in another.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 23:27, 13 October 21
imho !C should be reserved for the RAM disc to be compatible to RDOS.  :)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 04:33, 14 October 21
Quote from: GUNHED on 23:27, 13 October 21
imho !C should be reserved for the RAM disc to be compatible to RDOS.  :)


I partially agree, but... if no technical reason otherwise, a RAMDISC could just be another UniDOS node which can expose a physical device.  The benefits of the UniDOS way would be... you could have the Doberton RAMDISC, DkTronics one, the 3.5mb separate Jarek one etc or any other arrangements that can be assigned to any UniDOS letters.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 04:38, 14 October 21
In fact, i might have a go at making a RAMDISC, it might be easier to get working than the dropbox-like internet disc
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 21:09, 14 October 21
Quote from: zhulien on 19:37, 13 October 21
What is your thoughts on introducing a |c which can be assigned to any logical device?  I suspect it would be a lot less compatible than |a and |b?  But... some devices ROMs for example RAM drives historically had |c or |m.  Going further if |c could work reasonable well for most things, what about adding another bunch... or will it take away standard CPC RAM for the RSX registrations?

The reasons as follows.  The logical to physical behaviour works really really good in UniDOS, but 2 drives can be a bit of a pain if you only temporarily want to check the contents of somewhere (as an example) but continue your main work from one location, and play around in another.
Technically, it would be quite trivial to multiply the logical drives (in fact internally UniDOS could already handle all A-Z letters), but like you said it would introduce a compatibility issue which cannot be solved.
For instance, imagine that you start a classical software limited to A/B from a logical drive X, you cannot know what will happen (it will depend on the software, some might crash, others might automagically fallback to A... or B, unpredictible behavior).

That said, your point about easily dealing with several locations at the same time is right. I was also considering it, and I have several ideas to investigate which would not introduce compatibility issues.
In the meantime, as a first helper, you can already use symbolic links configured to your preferred locations (links can actually be used as bookmarks to paths) and just load them to go back/to these location.
In fact, symbolic links can be used for many many many different purposes.  8)

Quote from: zhulien on 04:33, 14 October 21
I partially agree, but... if no technical reason otherwise, a RAMDISC could just be another UniDOS node which can expose a physical device.  The benefits of the UniDOS way would be... you could have the Doberton RAMDISC, DkTronics one, the 3.5mb separate Jarek one etc or any other arrangements that can be assigned to any UniDOS letters.
Sure, you're totally right. There would no reason to force association of a logical drive to some hardware.
But nothing prevents you from calling your RAM disk physical drive "C:", even if "RAM:" sounds better to me. :)

Quote from: zhulien on 04:38, 14 October 21
In fact, i might have a go at making a RAMDISC, it might be easier to get working than the dropbox-like internet disc
It would be nice actually!
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 03:33, 16 October 21
libraries work fine once i put them into the library folder.


the only thing odd, DSK remains assigned to |b for example, but the library gets lost upon reboot

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 12:39, 16 October 21
Quote from: zhulien on 03:33, 16 October 21
libraries work fine once i put them into the library folder.

the only thing odd, DSK remains assigned to |b for example, but the library gets lost upon reboot
Mounted disc image file into the DSK: drive is always retained at reset, unless you reset the M4 itself.

Logical drives assignation has nothing to do with the fact that an image file is mounted or not inside DSK:.
It just work like any other drive with removable medias (DFA:, DFB:, UMS: ...).

For instance, if you assigned UMS: to logical drive B, removing the USB stick won't kill your assignation, you will just have a "media missing" when trying to access it (same as floppy discs).

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 21:34, 23 October 21
After using UniDOS for a full week (most nights), I think as many letters as you are able to assign would be a huge advantage.


Actually I forgot to test whether you catered for the other syntax in run, load etc...


eg: run"A:blah" and run"B:blah"

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 04:54, 26 October 21
UniDOS Scanning.


I am wondering what happens when UniDOS does a scan.  Does it look only at the ROMS extensions and then assume the devices are there, or does it do an initialisation of the devices upon scanning?


In a simple install, M4+XMem+YMem+X-Mass, it scans very fast.  As soon as I add a PlayCity, it can take a while.


What would cause that?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: xesrjb on 09:10, 26 October 21
I think, I must check this UniDos...


xesrjb
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 13:27, 26 October 21
If you have more than 1 mass storage, UniDOS is a must have, if you only have 1 mass storage, UniDOS still provides some useful features.  Eg: M4 vs UniDOS behaviour with RSXs vs changing the existing load, run etc... I like both ways, neither is wrong, UniDOS seems to be more compatible which I guess is why it is like that and if too many RSXs are added, it isn't always a good thing too for BASIC HIMEM.


As much as I'd like some additional features of UniDOS, even as it is, I wouldn't go back - because I am using multiple mass-storages at the same time.


Desperately want: more drive letters


a, b, c, d, f, g, h, i, m, r, s, t, u, x


a  & b - floppy drives & especially a for high compatibility for legacy software on any device
c - for compact flash
f - ftp mounted drive
g - gr8net mounted drive
h - harddisks
i - internet mounted drive

d - for mounted dsk
m & r - for ram drives
s - for sdcards
t - for a tape drive
u - native HxC USB

x - for x-mass


but of course we can assign any physical device to any letters we like from those which is awesome.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Prodatron on 13:47, 26 October 21
Quote from: zhulien on 04:54, 26 October 21As soon as I add a PlayCity, it can take a while.

What would cause that?
If the PlayCity is attached, you read 0-bytes on a very large range of I/O ports (at least between #f800 and #ffff).

Maybe this is confusing some hardware detection routines?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 11:53, 08 November 21
Quote from: zhulien on 04:54, 26 October 21
UniDOS Scanning.
In a simple install, M4+XMem+YMem+X-Mass, it scans very fast.  As soon as I add a PlayCity, it can take a while.
Each DOS node is scanning for its supported hardware. So, what Prodatron said sounds very possible.

You may want to check which DOS node stalls with the PlayCity (M4 or X-Mass) and then determine if the detection code can be improved (I can't check on my own I don't have these hardware).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 11:55, 08 November 21
Quote from: zhulien on 13:27, 26 October 21
Desperately want: more drive letters
With a proper shell management you won't need any single drive letter apart for AMSDOS backward compatibility. 8)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 21:54, 08 November 21
Great! Where can we take a look at this shell? Download?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: HAL6128 on 18:02, 12 November 21
Hi Offset,


I've installed today UniDOS for a trial at ROM7. Attached boards are M4 and Nova NVRAM. Unidos says "warning: no NVRAM found".
The only other ROMs are the patched ParaDOS at ROM15.
What could be the issue why the NVRAM isn't detected?


(The Nova board works fine by poking value into it via BASIC).



...got it working
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 18:49, 19 November 21
UniDOS 1.37 is available.


It is just a small fix improving AMSDOS compatibility in a very special use case triggered by Orgams with files smaller than 2K.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 20:10, 03 February 22
Since I do not know when further fixes will occur, I decided to release the long standing M4 DOS node 1.22 which has the FTP drive activated (it is more than 6 months old actually).

M4 Board firmware v2.0.8 or better is required to make it work, but as explained in the documentation of UniDOS website it won't be fully functionnal yet.
Some additional fixes might be required in M4 Board firmware to make if work at 100% but Duke do not have time to investigate on his side for now... and on my side I do not have access to a M4 Board anymore.

BTW, you can at least have a try, and maybe someone will find a workaround to get it work 100% with the current M4 firmware. 8)

Here is a small video of the FTP network drive feature:
http://amsnet.chez.com (http://amsnet.chez.com)

More information at:
https://unidos.cpcscene.net (https://unidos.cpcscene.net)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: norecess on 20:33, 03 February 22
this looks surreal @OffseT (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1826) ! The integration with amsdos is perfect !
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: XeNoMoRPH on 22:35, 03 February 22
Quote from: OffseT on 20:10, 03 February 22
Since I do not know when further fixes will occur, I decided to release the long standing M4 DOS node 1.22 which has the FTP drive activated (it is more than 6 months old actually).

M4 Board firmware v2.0.8 or better is required to make it work, but as explained in the documentation of UniDOS website it won't be fully functionnal yet.
Some additional fixes might be required in M4 Board firmware to make if work at 100% but Duke do not have time to investigate on his side for now... and on my side I do not have access to a M4 Board anymore.

BTW, you can at least have a try, and maybe someone will find a workaround to get it work 100% with the current M4 firmware. 8)

Here is a small video of the FTP network drive feature:
http://amsnet.chez.com (http://amsnet.chez.com)

More information at:
https://unidos.cpcscene.net (https://unidos.cpcscene.net)
M4 Board firmware v2.0.8 ... where is this version ?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 15:33, 04 February 22
Quote from: norecess on 20:33, 03 February 22
this looks surreal @OffseT (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1826) ! The integration with amsdos is perfect !
Only Amiga UniDOS makes it possible! :P

Quote from: XeNoMoRPH on 22:35, 03 February 22M4 Board firmware v2.0.8 ... where is this version ?
I'm afraid it is not officialy released/finalized yet. Duke will dig into it when he has time I guess (on my side, I had access to a 2.0.8beta, but it was just for test purposes).
Anyway, you can have a try with current 2.0.7; apart of the known M4 Board dead lock during reading files from FTP, it should work.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 12:19, 06 February 22
Version 1.4 of uniDOS Cartridge Creator was published on https://unidos.cpcscene.net (https://unidos.cpcscene.net) download's section.

No big changes, mainly a Linux  :-\  native version was added which seems to work even if for unknown reasons the window in opened shrinked, which hides the ROM list; just resize it. :)
Also, for some reason, it refuses to display the window with the progress bar during ROM downloading (I guess Linux hates me as much as I hate him)... but downloading works any way.

Native versions for MorphOS 8) , AmigaOS 3.x ;D , AmigaOS 4.x ::) , Windows 64-bit :blank: and Windows 32-bit :-X (which is perfectly working with Wine of Linux) are also still available.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 16:16, 07 February 22
Pretty cool advancements - UniDOS becomes the FutureDOS for the native OS.  :)  It's a great thing to eventually unify everything to a unique DOS. For far too long people did their own things, which didn't allow to have synergy effects. I really like to see how UniDOS evolves. You do a very great job!  :) :) :)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Cwiiis on 23:25, 21 February 22
I was just updating unidos on my machine and noticed there's now a patched firmware which would be very handy on the Plus... Has anyone had any success with it? If I flash it, it's clearly corrupt (nonsense rom name and version) and I can't boot from it... I guess the file isn't formatted the same as the other rom files on the site? (which all flash fine) Anyone had any joy with it on the X-MEM?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 15:17, 16 March 22
Quote from: Cwiiis on 23:25, 21 February 22I was just updating unidos on my machine and noticed there's now a patched firmware which would be very handy on the Plus... Has anyone had any success with it? If I flash it, it's clearly corrupt (nonsense rom name and version) and I can't boot from it... I guess the file isn't formatted the same as the other rom files on the site? (which all flash fine) Anyone had any joy with it on the X-MEM?

On Plus you have the ability to upgrade ROM 7 without patching the motherboard. Patched firmware is not required for optimal compatibility.

Anyway, the firmware ROM files from UniDOS web site are using the same file format than other ROMs.

About ROM name and ROM version, it is normal, because the firmware ROM (which is a lower ROM) do not matches the other ROMs tags (which are upper ROMs).
Are you sure that you actually flashed the firmware ROM in the lower slot and not in an upper ROM slot?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Cwiiis on 15:29, 16 March 22
Quote from: OffseT on 15:17, 16 March 22
Quote from: Cwiiis on 23:25, 21 February 22I was just updating unidos on my machine and noticed there's now a patched firmware which would be very handy on the Plus... Has anyone had any success with it? If I flash it, it's clearly corrupt (nonsense rom name and version) and I can't boot from it... I guess the file isn't formatted the same as the other rom files on the site? (which all flash fine) Anyone had any joy with it on the X-MEM?

On Plus you have the ability to upgrade ROM 7 without patching the motherboard. Patched firmware is not required for optimal compatibility.

Anyway, the firmware ROM files from UniDOS web site are using the same file format than other ROMs.

About ROM name and ROM version, it is normal, because the firmware ROM (which is a lower ROM) do not matches the other ROMs tags (which are upper ROMs).
Are you sure that you actually flashed the firmware ROM in the lower slot and not in an upper ROM slot?

Ah, I probably wasn't flashing it in the correct position, thanks for the clarification. Regarding upgrading rom 7, I don't seem to have any success trying to flash rom 7 - I can replace it by using a custom cart or the C4CPC, though it seems anything that doesn't have the ACID chip introduced a lot of instability with expansions, so I tend to just use the stock cart. I'd be interested in hearing exactly how someone replaced rom 7 on a Plus without a custom cartridge.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 18:18, 16 March 22
Quote from: Cwiiis on 15:29, 16 March 22I'd be interested in hearing exactly how someone replaced rom 7 on a Plus without a custom cartridge.
You can easily acheive this with all existing rom boards... but the X-Mem.
Here I'm using the MegaFlashGordon from PulkoMandy.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: TotO on 18:41, 16 March 22
@Cwiiis You can use a D-ROM board or a M4 board to do that. The MegaFlashGordon is a old design clone of the Mega Flash that do not provide extra-features like booting from a different firmware.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 19:02, 16 March 22
Quote from: TotO on 18:41, 16 March 22@Cwiiis You can use a D-ROM board or a M4 board to do that. The MegaFlashGordon is a old design clone of the Mega Flash that do not provide extra-features like booting from a different firmware.
Well, the (Mega)FlashGordon is just perfect, it is small and efficient and provides manual switch for alls ROMs, ROM 0 (hacker) and ROM 7.
Very little people actually needs to replace the firmware (I never did).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Cwiiis on 19:04, 16 March 22
Quote from: OffseT on 18:18, 16 March 22
Quote from: Cwiiis on 15:29, 16 March 22I'd be interested in hearing exactly how someone replaced rom 7 on a Plus without a custom cartridge.
You can easily acheive this with all existing rom boards... but the X-Mem.
Here I'm using the MegaFlashGordon from PulkoMandy.

I'll test it out on the RSF3 - it has the option, but you have to explicitly enable it... Which felt risky, but sounds like it's not an issue, so I'll try it out :)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: TotO on 21:14, 16 March 22
Quote from: OffseT on 19:02, 16 March 22Well, the (Mega)FlashGordon is just perfect, it is small and efficient and provides manual switch for alls ROMs, ROM 0 (hacker) and ROM 7.
Very little people actually needs to replace the firmware (I never did).
I'm not here to say what peoples actually needs, just to let known there is more alternative. If Cwilis own a C4CPC, it is the best to use in fact. No need to add something on the expansion port. If I'm not wrong, it is required to program the DOS on the physical ROM3 to be seen as logical ROM7?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 01:24, 17 March 22
Quote from: TotO on 21:14, 16 March 22I'm not here to say what peoples actually needs, just to let known there is more alternative. If Cwilis own a C4CPC, it is the best to use in fact. No need to add something on the expansion port. If I'm not wrong, it is required to program the DOS on the physical ROM3 to be seen as logical ROM7?
Sure, but as he said that he preferred not to use the C4CPC and asked how to replace the ROM 7 while using the regular cartridge, the best option is then "any ROM board but the X-Mem".

Quote from: Cwiiis on 19:04, 16 March 22I'll test it out on the RSF3 - it has the option, but you have to explicitly enable it... Which felt risky, but sounds like it's not an issue, so I'll try it out :)
Actually, it should work with RSF3. There is no risk to enable ROM 7 on Plus (ROM 7 from cartridge is automatically disabled when an external one is provided).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: TotO on 12:38, 17 March 22
Quote from: OffseT on 01:24, 17 March 22Sure, but as he said that he preferred not to use the C4CPC and asked how to replace the ROM 7 while using the regular cartridge
He said he can replace it by using a custom cart or the C4CPC, but that introduced a lot of instability with expansions and you answered that he can replace the ROM7 by using a romboard while using a regular cartridge.

So, the problem is more to know why he has instability by using the C4CPC on his Plus. Better to ask to @gerald or other unidos users to try to find the real problem a not a workaround.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 21:02, 17 March 22
Quote from: TotO on 12:38, 17 March 22He said he can replace it by using a custom cart or the C4CPC, but that introduced a lot of instability with expansions and you answered that he can replace the ROM7 by using a romboard while using a regular cartridge.
So, the problem is more to know why he has instability by using the C4CPC on his Plus. Better to ask to @gerald or other unidos users to try to find the real problem a not a workaround.
Let's say it again in a simplier way:

Question: "I'd be interested in hearing exactly how someone replaced rom 7 on a Plus without a custom cartridge."
Answer: "Use any ROM board but the X-Mem."

Sounds crystal clear to me.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 22:23, 17 March 22
Or any ROM board being capable of replacing ROM 7. :)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: TotO on 09:57, 18 March 22
Quote from: OffseT on 21:02, 17 March 22Let's say it again in a simplier way:
Question: "I'd be interested in hearing exactly how someone replaced rom 7 on a Plus without a custom cartridge."
That is not what he was originally asked to you, but a question following to what you are suggesting for a workaround to his initial issue. I just think to fix his problem, he has better to looks around the C4CPC.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 15:27, 18 March 22
Quote from: TotO on 09:57, 18 March 22That is not what he was originally asked to you, but a question following to what you are suggesting for a workaround to his initial issue. I just think to fix his problem, he has better to looks around the C4CPC.
Really? Please, read again the inital answer.
It explains both that the Firmware patch was not properly installed (might be installed as upper ROM instead of lower), and that on a Plus it is not the best solution since ROM 7 can be overridden (which is the optimal option).
Then he asked about how to override ROM 7...

But, well, I guess I've got the point. :)
As suggested by GUNHED, let's rephrase it one more time in a way that may not upset you (hopefully):

Question: "I'd be interested in hearing exactly how someone replaced rom 7 on a Plus without a custom cartridge."
Anwser: "Use any ROM board being capable of replacing ROM 7."
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 16:27, 18 March 22
can the Albireo rom be easily modified to work with USB on the minibooster?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 21:23, 18 March 22
Quote from: zhulien on 16:27, 18 March 22can the Albireo rom be easily modified to work with USB on the minibooster?
No, the Albireo node relies on the CH376 chip of the Albireo, it is not related to serial UART/USB at all.

But handling USB serial from MiniBooster should be quite trivial to add to the (not yet released) serial node.
This node supports standard Y-Modem protocol over (Albireo) serial UART/USB, which can be used directly (via transfer RSX) or as a filesystem (thru a new SERIAL: drive).

Unfortunately I have no clue when it will be actually released (I'm not the author of this upcoming node).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: TotO on 22:31, 18 March 22
Quote from: OffseT on 15:27, 18 March 22Really? Please, read again the inital answer.
It explains both that the Firmware patch was not properly installed (might be installed as upper ROM instead of lower), and that on a Plus it is not the best solution since ROM 7 can be overridden (which is the optimal option).
Then he asked about how to override ROM 7...

But, well, I guess I've got the point. :)
As suggested by GUNHED, let's rephrase it one more time in a way that may not upset you (hopefully)
I have read some times the discussion to be sure to have missed nothing of the exchange, thinking about his initial problem. I have well understood the questions, I'm just thinking the final answer was not related to that.

No worry, the goal was not to flood the topic, but to try to point the divert of the initial issue.

Have a nice weekend! ;)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 01:24, 19 March 22
I confirm everything was related and both the initial issue (mistake during u5 patched firmware ROM installation) and the better alternative (using u5 patched firmware being pointless on Plus since ROM 7 can be overidden) was answered.

BTW, both will work (even using nor ROM 7 slot neither u5 patched firmware, at cost of compatibility). Then, it is up to the users to decide what best fit their usage/hardware. :)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 12:19, 22 April 22
One thing CubeMDos handles is direct access for HxC/Gotek 
Note: the SymbOS equivalent doesn't work for me.

Not using that feature very often, but very handy when needed.

I'm going to try making CubeMDos and Unidos cohabit! Cubidos.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: TotO on 14:11, 22 April 22
Quote from: m_dr_m on 12:19, 22 April 22I'm going to try making CubeMDos and Unidos cohabit! Cubidos.
Or CuniDOS. Cheers! :P
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 14:36, 22 April 22
I think we need this new DOS. Just for the name, and in the name (of god).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 10:58, 26 April 22
Quote from: m_dr_m on 12:19, 22 April 22One thing CubeMDos handles is direct access for HxC/Gotek
Yeah. That's in the todolist and it looks quite trivial to add support for this in the FatFs node (a matter of couple of days to implement or so ^^).
In addition to the IDE: drive, the FatFs node could provide HXCA: and HXCB: drives (or whatever name given to them).

Unfortunately, I don't have regular access to a HxC, but if someone can provide me with validated low level routines to access HxC SD card sectors I can try some blind implementation. :)
Powered by SMFPacks Menu Editor Mod