CPCWiki forum

General Category => Applications (CPC and CPC-related) => Topic started by: OffseT on 15:51, 24 January 21

Title: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 15: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 17:18, 24 January 21
Wow, great project and great doc !
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: HAL6128 on 19: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 22:14, 24 January 21
Quote from: HAL 6128 on 19: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 22:18, 24 January 21
Quote from: OffseT on 15: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 11:50, 25 January 21
So, does
|dir,"**/3d*"
work? (:



Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 15:11, 25 January 21
Quote from: m_dr_m on 11: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 19: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 15:48, 25 January 21
Quote from: GUNHED on 22: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 18: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 21:22, 25 January 21
Quote from: GUNHED on 18: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 07: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 12: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 02:08, 27 January 21
Quote from: OffseT on 15: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 02: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 18:51, 29 January 21
Quote from: zhulien on 02: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 19:01, 29 January 21
Quote from: GUNHED on 22: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 19:43, 29 January 21
Quote from: OffseT on 19: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 12:09, 30 January 21
Quote from: OffseT on 18: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 14:02, 30 January 21
Quote from: zhulien on 12: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 14:25, 30 January 21
Quote from: zhulien on 12: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 14: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 12: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 19:16, 06 February 21
Quote from: Targhan on 12: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 19:36, 06 February 21
Quote from: OffseT on 19: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 20: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 20: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 21: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 11:51, 08 February 21
Quote from: Targhan on 20:57, 06 February 21
Some remarks:
- A little note in the doc about FAT16 not working could help some people (like me :) ).
- It took me a bit of time to understand that ":" must be put when using the Drive command. ùdrive,"a","SD:" or "DFA:". Maybe a shortcut without ":" could be done? Anyway, there is no direct example in the doc about such simple command, you should add it.
- Also add an example like "load"DFA:"" to show how quickly one can change the drive.
I just didn't imagine one could use anything else than FAT32 for the SD card. :)


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


I will add some remarks in the documentation.  8)


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

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


Anyway, it easier to extract files from DSK to directories and access them directly from there; faster also.  :P
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: SOS on 07:04, 09 February 21
Quote from: Targhan on 21:02, 06 February 21But I don't think a CPC has the firepower to do that.
Hmmm, an DSK-Emulation is from the speed more than a real floppy, as an USB/SD-MassStorage.
Yes, the CPC has the firepower, but the speed is "retro".
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Targhan on 09:25, 09 February 21
Quote from: SOS on 07:04, 09 February 21Yes, the CPC has the firepower, but the speed is "retro".

The speed is not the problem I had in mind. To me, the problem is handling a 200k DSK file, not quite simple on CPC.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: SOS on 09:54, 09 February 21
Quote from: Targhan on 09:25, 09 February 21To me, the problem is handling a 200k DSK file, not quite simple on CPC.
Correct ;-)

Offset said correctly
"It is just a lot of work (DSK file format management plus AMSDOS emulation over DSK)"
The convert from "Track/Head/Sector" to an LBA-Value is a little bit tricky.
When you want to do that, (Tip) use an hardware which have an reliable LBA-Read-Sector-Function (XMASS, SF2/3)
IMHO you will not get an success when you try to use FileI/O's for an DSK-Emulation
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 10: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 12:05, 09 February 21
Quote from: OffseT on 10:48, 09 February 21Regarding memory, it should not require more memory than regular floppy handling (in fact, it should even require less).
You need more memory as a normal floppy interface, e.g. LBA-Start of the DSK-File, DSK-Geometrics, ...
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 12:31, 09 February 21
Quote from: SOS on 12:05, 09 February 21
You need more memory as a normal floppy interface, e.g. LBA-Start of the DSK-File, DSK-Geometrics, ...


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

But again, I see very little interest in handling DSK file since we can erradicate them. 8)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 13: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 21: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 18:24, 14 February 21
Quote from: m_dr_m on 21:20, 13 February 21
Besides DSKs, do you see a solution to preserve CAT Arts?
CAT arts stored on floppies should work as-is.


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


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


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


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

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 10:10, 17 February 21

With the DOS Nodes, DOSNode_GetFreeSpace returns 32 size in kilobytes, maximum of 64megabytes?  how would a mass storage like an SD card be handled?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 10: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 15: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 16:44, 17 February 21
Quote from: zhulien on 10:10, 17 February 21
With the DOS Nodes, DOSNode_GetFreeSpace returns 32 size in kilobytes, maximum of 64megabytes?  how would a mass storage like an SD card be handled?
Maximum is 4 TB.



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

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


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


There is no "SetFileSize" API yet; it might be added in the future.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 00:00, 18 February 21
Thanks, with regard to the 2k non-volatile memory, am I correct in that we can have filesystem nodes that can provide a subset of full functionality by not implementing the non-volatile memory functions?  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 17:05, 18 February 21
Quote from: zhulien on 00:00, 18 February 21
Thanks, with regard to the 2k non-volatile memory, am I correct in that we can have filesystem nodes that can provide a subset of full functionality by not implementing the non-volatile memory functions? 

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


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


UniDOS adapts its behavior depending on DOS node capabilities.


Quote from: zhulien on 00:00, 18 February 21
Also is it likely that one of the reserved 7 functions would be later used for a device status, such as... is it write protected, is it readonly (i.e. could be a CDROM or internet FS) so that developers can make software that behaves instead of just erroring?
DOSNode_GetStatus already gives this kind on information about drives/medias capabilities, which is then available for the final UniDOS user though the "cmd_device_info" command of CTRL-J BIOS.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 01: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 15:11, 16 March 21
Quote from: zhulien on 01:28, 12 March 21
Are extension nodes already working for UniDOS now? [...]
Sure. The already published Albireo node is fully functionnal and stable.

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


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


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

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

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 16:57, 20 March 21
I created a skeleton file to fill in all the code for an extension, what is the reason for returning statuses in the C flag?  I would have used Z flag.  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 22: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 10:28, 21 March 21
Quote from: zhulien on 16:57, 20 March 21
I created a skeleton file to fill in all the code for an extension, what is the reason for returning statuses in the C flag?  I would have used Z flag.  [...]
Targhan is right, C flag is easy to use. But in most routines, you will see that both C and Z flags are used (C for feature availability and Z for actual feature status).


May I ask which extension you plan to support?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 14:09, 21 March 21
Quote from: OffseT on 10:28, 21 March 21
May I ask which extension you plan to support?


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


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


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


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

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 10:16, 22 March 21
Quote from: zhulien on 14:09, 21 March 21
Actually I am not sure yet, I am hoping it isn't too hard to create a virtual fs on a webserver.
Sounds interesting. 8)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 12: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 17:35, 08 April 21
Quote from: m_dr_m on 12: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 17: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 10: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 15:44, 09 April 21
Quote from: m_dr_m on 10: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 10: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 10: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 18: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 09:28, 11 April 21
Quote from: GUNHED on 18: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 13:03, 13 April 21
Great!
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 09: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 09: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 20:08, 19 April 21
Quote from: Targhan on 09: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 21: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 21: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 13:35, 21 April 21
Quote from: zhulien on 21: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 21: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 08:15, 23 April 21
Quote from: zhulien on 21: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 20:03, 23 April 21
Quote from: OffseT on 08: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 20:34, 23 April 21
Quote from: GUNHED on 20: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 10: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 10:12, 28 April 21
Quote from: zhulien on 10: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 10: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 11:48, 28 April 21
Quote from: m_dr_m on 10: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 10: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 10: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 10: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 10: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 11:56, 28 April 21
Quote from: m_dr_m on 10: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 14: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 15: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 18:41, 28 April 21
Quote from: zhulien on 14: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 18:44, 28 April 21
Quote from: m_dr_m on 15:46, 28 April 21
It's quite disturbing to see the X-Mass active for each floppy access. Makes you wonder if the right drive is selected.
I agree. Did you try to remove the X-Mass LED?  :laugh:

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

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

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

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

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

Quote from: m_dr_m on 12:36, 02 May 21Request:
* |MKDIR alias for save"toto/" which would give back control (if I try to create a directory via save in BASIC, it stops the program)
* |CD alias for load"dir" (same reason + uniformity with other DOS)
* Access to parent dir (e.g. load"../dump")
* A list of current known issue and current requests + status !
The fact that SAVE/LOAD on directories stops the program is a feature.  8)  But I agree that it forces you to handle errors to be able to auto-resume, which is sometimes a bit overkill.
RSX aliases for creating and entring directories was discussed at some point, but it was finally not selected. Anyway, it could be added eventually.
BTW, parent dir access is already supported (Changement de répertoire (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 12:57, 02 May 21Good point, I like uniformity too. Yet I also enjoy Morse entropy principle: * Frequent commands should be short * Less frequent commands can be long Plus: * Modifying commands should be explicit
Both short and long/explicit syntaxes could exist. No reason to keep only a cryptic form just because it is of a frequent usage.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 08:19, 03 May 21
Quote from: OffseT on 23:34, 02 May 21
The fact that SAVE/LOAD on directories stops the program is a feature.   
Wat? It also stops the program on success, which is not consistent with load/save for binaries.


Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 10:33, 03 May 21
Quote from: m_dr_m on 08:19, 03 May 21
Wat? It also stops the program on success, which is not consistent with load/save for binaries.
Details here: LOAD/SAVE sur des répertoires (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 11:27, 03 May 21
Quote from: OffseT on 23:34, 02 May 21This is actually equivalent to what's done everytime a CAS_* that needs to be redirected to the AMSDOS/ParaDOS call is done.
Yep that exactly the problem! For Orgams that's every 2kb, for Starkos it would be every byte (one hour to load?).

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



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

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

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



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

This DOS node could comply with UniDOS memory management, and if required, it could handle additional memory in a system-friendly manner (like FatFs does).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 17:01, 03 May 21
Quote from: OffseT on 12:13, 03 May 21
... correct with X-Mass NVRAM and ...
Where do you have nvRAM in the X-MASS?
How to access it?

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 17:36, 03 May 21
Quote from: GUNHED on 17:01, 03 May 21
Where do you have nvRAM in the X-MASS?
How to access it?
It is emulated either thru a file on the file system (default mode) or by using some raw sectors (fatfs.cache.on mode) which are located between the partition table and the first partition.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 01: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 08: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 10: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 12:27, 04 May 21
To each its own, I'm used to reactivity on CPC!
Also, I use it extensively for coding.



Anyway, why not both? Reliable and fast.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 13:27, 04 May 21
UniDOS is actually focussed on compatiliby and reliability, but also, it proposes a unique solution so that all existing hardwares could be used all together in the same manner.



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


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


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


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

Both is the goal. But when you have to choose: first reliability, then the speed.
And Albireo node already achieves both quite nicely. 8)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Ast on 14:44, 04 May 21
Quote from: OffseT on 13:27, 04 May 21
UniDOS is actually focussed on compatiliby and reliability, but also, it proposes a unique solution so that all existing hardwares could be used all together in the same manner.


Unique ? I am not all right with that fact.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 15: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 15: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 15: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 15: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 18: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 18:50, 05 May 21
double post
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 15:36, 07 May 21
Quote from: GUNHED on 18: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 15: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 11: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 10: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 10: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 09: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 11: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 14: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 17:40, 29 May 21
Quote from: OffseT on 14: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 18: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 19:08, 29 May 21
Quote from: OffseT on 14: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 12: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 17: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 01:45, 08 June 21
Quote from: GUNHED on 19: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 02:53, 08 June 21
Quote from: Audronic on 01: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 03:24, 08 June 21
Quote from: GUNHED on 02: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 07: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 08: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 08:52, 08 June 21

Quote from: PulkoMandy on 07: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 07: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 09:25, 08 June 21
Quote from: TotO on 08: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 10: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 10: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 10: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 11: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 12: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 13:08, 08 June 21
Quote from: Audronic on 03: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 07: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 15: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 23:36, 08 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 10: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 13: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 14: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 12: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 13:34, 11 August 21
Quote from: OffseT on 12: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 12: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 15:51, 21 August 21
"the publisher has marked video as private"
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 16:22, 21 August 21
Quote from: roudoudou on 15: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 14: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 12:58, 08 September 21
Quote from: OffseT on 14: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 13:49, 08 September 21
Quote from: zhulien on 12: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 14: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 00:28, 09 September 21
Quote from: ComSoft6128 on 14: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 09:13, 09 September 21
Quote from: ComSoft6128 on 14: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 09:17, 09 September 21
Quote from: zhulien on 00: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 17: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 09: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 15:50, 19 September 21
Quote from: ComSoft6128 on 14: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 16: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 11: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 11:51, 20 September 21
Quote from: OffseT on 15: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 13:18, 20 September 21
Quote from: m_dr_m on 11: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 23:02, 21 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 01:09, 22 September 21
Quote from: Maniac on 23:02, 21 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 08:13, 22 September 21
Quote from: Cwiiis on 01: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 11:49, 22 September 21
Quote from: Maniac on 08: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 16: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 18: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 14:01, 23 September 21
Quote from: Maniac on 18: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 18:39, 23 September 21
Quote from: OffseT on 11: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 18:47, 23 September 21
Quote from: gerald on 18: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 19: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 19: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 23:11, 23 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 09:40, 24 September 21
Quote from: gerald on 19: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 14:47, 24 September 21
Quote from: OffseT on 19: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 15: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 17:55, 24 September 21
Quote from: Maniac on 15: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 18:57, 24 September 21
Quote from: OffseT on 17: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 16: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 18: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 18: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 18:53, 08 October 21
Quote from: m_dr_m on 18: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 18: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 19: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 19: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 19:31, 08 October 21
Quote from: zhulien on 19: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 19:40, 08 October 21
Quote from: zhulien on 16: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 19: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 19:49, 08 October 21
Quote from: OffseT on 19: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 19: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 20: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 20: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 21: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 08: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 09:00, 09 October 21
Quote from: zhulien on 21: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 09:07, 09 October 21
Quote from: zhulien on 20: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 20: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 13:37, 09 October 21
Quote from: OffseT on 08: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 13:42, 09 October 21
Quote from: OffseT on 09: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 15:52, 09 October 21
Quote from: zhulien on 13: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 16:23, 10 October 21
|library doesn't list anything
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 16:35, 10 October 21
Quote from: zhulien on 16: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 05: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 08:32, 11 October 21
Quote from: zhulien on 05: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 17: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 21: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 02:33, 14 October 21
Quote from: GUNHED on 21: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 02: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 19:09, 14 October 21
Quote from: zhulien on 17: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 02: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 02: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 01: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 10:39, 16 October 21
Quote from: zhulien on 01: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 19: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 02: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 07: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 11: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 11:47, 26 October 21
Quote from: zhulien on 02: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 10:53, 08 November 21
Quote from: zhulien on 02: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 10:55, 08 November 21
Quote from: zhulien on 11: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 20: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 17: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 17: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 19: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: norecess464 on 19: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 21:35, 03 February 22
Quote from: OffseT on 19: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 14:33, 04 February 22
Quote from: norecess on 19: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 21: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 11: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 15: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 22: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 14:17, 16 March 22
Quote from: Cwiiis on 22: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 14:29, 16 March 22
Quote from: OffseT on 14:17, 16 March 22
Quote from: Cwiiis on 22: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 17:18, 16 March 22
Quote from: Cwiiis on 14: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 17: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 18:02, 16 March 22
Quote from: TotO on 17: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 18:04, 16 March 22
Quote from: OffseT on 17:18, 16 March 22
Quote from: Cwiiis on 14: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 20:14, 16 March 22
Quote from: OffseT on 18: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 00:24, 17 March 22
Quote from: TotO on 20: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 18: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 11:38, 17 March 22
Quote from: OffseT on 00: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 20:02, 17 March 22
Quote from: TotO on 11: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 21: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 08:57, 18 March 22
Quote from: OffseT on 20: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 14:27, 18 March 22
Quote from: TotO on 08: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 15: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 20:23, 18 March 22
Quote from: zhulien on 15: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 21:31, 18 March 22
Quote from: OffseT on 14: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 00: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 10: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 12:11, 22 April 22
Quote from: m_dr_m on 10: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 12: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 08:58, 26 April 22
Quote from: m_dr_m on 10: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. :)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 15:28, 07 September 22
UniDOS 1.38 is now available!

In this version we have:

Please note that in addition to UniDOS main ROM, all DOS nodes were also updated.

More information at:
https://unidos.cpcscene.net (https://unidos.cpcscene.net)

Currently, UniDOS is already supporting the following devices:

To make the most versatile DOS even better, help is still wanted on the following topics:

Help could be some direct man power (full developper documentation about DOS nodes creation is available on UniDOS website), code sharing, but also lending me somes devices so that I could work on them (like Chany kindly did for the M4 Board support).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 19:40, 23 September 22
@OffseT please add additional aliases than just A and B, that will make life really really easier, i.e. I could make L for libraries and D for dev, T for temp etc.  the way they are assigned if fantastic, just A and B though is not enough.  (add that feature to the wish list above)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 15:10, 27 September 22
Such feature will be addressed in future versions of UniDOS, but not by simply adding logical drive letters, which is quite limited and does not provide any advantage regarding backward compatibility (softwares limited to drives A/B won't work with additional letters anyway). Something much better will be integrated into UniDOS. ;)

But you will have to wait a little bit, because some other cool features are planned to be released before. :D
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 21:22, 27 September 22
Quote from: OffseT on 15:10, 27 September 22Such feature will be addressed in future versions of UniDOS, but not by simply adding logical drive letters, which is quite limited and does not provide any advantage regarding backward compatibility (softwares limited to drives A/B won't work with additional letters anyway). Something much better will be integrated into UniDOS. ;)

But you will have to wait a little bit, because some other cool features are planned to be released before. :D

I almost found a good solution, that is with the softlinks.  I made a devs folder with a, b, m4, ide etc in it, this works well except... changing to it loses the devs folder for the 2nd time around.

I was thinking this could be done with a special logical drive dev, perhaps |dev... instead of changing to the logical folder as |a and |b does, it would assign the logical folder of |dev to whatever the current drive is (a or b) meaning that |dev could be setup once to any devs folder on any device someone chooses, then they can always get to it regardless of whether they are on a or b.  Load"dev:" or Load"dev:ide" would also do the same - still remaining on the current logical drive.

if dev was configured to m4:dev with |drive,"DEV","m4:dev"

then

|dev if on a drive a currently would be equivalent to |drive,"A","m4:dev"
|dev if on a drive b currently would be equivalent to |drive,"B","m4:dev"

Perhaps not the most elegant solution, but it will give a unix type dev folder of 100s of locations.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 10:27, 28 September 22
Quote from: zhulien on 21:22, 27 September 22I almost found a good solution, that is with the softlinks.  I made a devs folder with a, b, m4, ide etc in it, this works well except... changing to it loses the devs folder for the 2nd time around.
Yes, you are right. Symbolic links can be used for this purpose. That's a good tip.

Quote from: zhulien on 21:22, 27 September 22I was thinking this could be done with a special logical drive dev, perhaps |dev...
If I understood correctly your requirements, I would say that you could already create that kind of RSX in a separated program (ROM or RAM). Without argument it would simply assign the current logical drive to a new path, with an argument it would let you configure the dev path. Maybe, as an ultimate generic solution, you could create a RSX which works like the |ALIAS from RODOS!

Anyway, something similar to what you described is actually planned in UniDOS. :D
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 22:05, 29 September 22
I have actually looked at RODOS a couple of times and been totally confused with it - I know they advertised the benefits in one of the Amstrad Actions, but how to use it... the manual is terrible.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Barjack on 14:03, 30 September 22
Hello Mr Set,
Is it possible to have a different color on the directories with an ùcat command ?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 17:46, 30 September 22
Quote from: zhulien on 22:05, 29 September 22I have actually looked at RODOS a couple of times and been totally confused with it - I know they advertised the benefits in one of the Amstrad Actions, but how to use it... the manual is terrible.
Yeah, RODOS is not that easy to use at first try, notably because drives are numbers. But it was certainly the most powerful DOS around, its main drawback being the huge amount of memory it allocated, making it incompatible with most softwares.

Quote from: Barjack on 14:03, 30 September 22Hello Mr Set,
Is it possible to have a different color on the directories with an ùcat command ?
Your request comes too late, it is already implemented in UniDOS 1.40... because...

Here it is!

UniDOS 1.40 is now available! 8)

It comes with:

Enjoy! :P
» https://unidos.cpcscene.net
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Barjack on 18:05, 30 September 22
It's incredible, Mr Set !
And would it be possible to have a launcher that works under UniDOS?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: ComSoft6128 on 18:31, 30 September 22
Quote from: zhulien on 22:05, 29 September 22I have actually looked at RODOS a couple of times and been totally confused with it - I know they advertised the benefits in one of the Amstrad Actions, but how to use it... the manual is terrible.
Over here RODOS was ditched quite quickly by users in favour of ROMDOS (and later ParaDos) - it had a reputation as being difficult to use. The first version might have been bugged as well.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: gms0012 on 09:35, 20 October 22
can anybody please show me a ROM-config for CPC6128+M4

I dont get it working... tried each variant...

thx
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 20:28, 20 October 22
Quote from: gms0012 on 09:35, 20 October 22can anybody please show me a ROM-config for CPC6128+M4
Without any further information, I suppose your CPC6128 motherboard is not patched for the ROM 7 disabling?

Then, first you need to set-up your M4 board built-in ROM to any slot after 31; 127 is a good choice as explained here: https://unidos.cpcscene.net/doku.php?id=fr:install#nœud_dos_m4

One done, you should program UniDOS ROM to slot 5 (which gives you the option to later use the patched "u5" firmware) and the M4 DOS Node ROM any slot lower than 16 (except slot 7 which is fixed to AMSDOS on unpatched CPC6128).

To sum-up everything, a good configuration could be:
Built-in M4 Board ROM to slot 127.
UniDOS to slot 5.
M4 DOS node ROM to slot 4.

And then, if you want to achieve a better compatibility with games, utilities and demos, you could also set-up your M4 lower ROM slot to 31, and to put there the patched "u5" firmware ROM from UniDOS download page.

I hope it will help, don't hesitate to provide me with more details about your configuration attempts if you still have issues.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: gms0012 on 07:38, 21 October 22
Hello and thank you for the reply.. looks like it is working now... thanks for your help

I have this in my m4 settings (2.0.7)

ENABLED true
ROM NUMBER 127
ROMBOARD Start 0
LOWER ENABLET true
LOWER ROM SLOT 31

Slot2: M4FE
Slot 4: M4 Node
Slot 5: UNIDOS
 
Slot 31: AMSDOS - patched

but when I want to start another ROM like m4fe...I got the message "no m4 board detected"...

when I enter |DRIVE -> i see my m4 sd

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 15:33, 21 October 22

PM sent.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 11:34, 22 October 22
Quote from: gms0012 on 07:38, 21 October 22but when I want to start another ROM like m4fe...I got the message "no m4 board detected"...
M4FE relies exclusively on M4 board built-in ROM custom commands to operate. For compatibility reason, these commands are disabled when using UniDOS, that's why M4FE fails to detect M4 Board (actually, it does not seem to detect the M4 Board itself but only the RSX provided by its built-in ROM).

As-is, it is a no go to make it work with UniDOS, some adaptations in M4FE would be required.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: gms0012 on 13:20, 22 October 22
ok. thanks for the information and help :)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 22:04, 04 November 22
UniDOS 1.50 was released! 8)

This is a major release with a lot of visible and invisible modifications.
All DOS nodes were also updated.

For the end user, the most notable update is the full time and date support as well as new RSX.
For the developers, new BIOS and node API came up.

More details on https://unidos.cpcscene.net
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 00:08, 17 June 23
I have been playing with UniDOS 1.5, it seems to fix quite a few bugs from 1.3x...  However, I cannot use the new UNITOOLS because it locks up scanning, it took a long time to find, but i think it is because i don't have a floppy drive but a floppy emulator - likely the behaviour is why you mention some 3.5" drives make it incompatible.

Any chance for 2 builds of UNITOOLS?  one for scanning boot devices, and one that does not?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 21:26, 18 June 23
@OffseT I think I found a couple of UniDOS bugs, possibly with the M4 driver.  That is sometimes getting duplicate entries when performing a CAT and sometimes getting file sizes in G instead of K.  Performing a CAT again, may or may not show the same error or be correct.  I tested on M4 and X-MASS but could only reproduce it (without any obvious pattern) on the M4.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 23:47, 18 June 23
Quote from: zhulien on 21:26, 18 June 23@OffseT I think I found a couple of UniDOS bugs, possibly with the M4 driver.  That is sometimes getting duplicate entries when performing a CAT and sometimes getting file sizes in G instead of K.  Performing a CAT again, may or may not show the same error or be correct.  I tested on M4 and X-MASS but could only reproduce it (without any obvious pattern) on the M4.
Very often also when saving a BASIC program over the top of an existing one, it might fail with filenames stuck as MYPROG.$$$ which for some reason cannot be deleted with the era command.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 14:25, 19 June 23
Quote from: zhulien on 23:47, 18 June 23
Quote from: zhulien on 21:26, 18 June 23@OffseT I think I found a couple of UniDOS bugs, possibly with the M4 driver.  That is sometimes getting duplicate entries when performing a CAT and sometimes getting file sizes in G instead of K.  Performing a CAT again, may or may not show the same error or be correct.  I tested on M4 and X-MASS but could only reproduce it (without any obvious pattern) on the M4.
Very often also when saving a BASIC program over the top of an existing one, it might fail with filenames stuck as MYPROG.$$$ which for some reason cannot be deleted with the era command.
I'm not aware of this kind of issue. AFAIK, M4 node is stable with latest M4 Board firmware version. For now, the only known issue is related to the sockets which are not working are expected when dealing with FTP: drive (M4 firmware freezes on reading files from FTP:).

You should check:
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 14:38, 19 June 23
Thanks for the tips, I will remove the 2nd Mx4 board to see if power may be the issue, however I am using an external PSU on the 2nd Mx4 board.  I just formatted the sdcard again to see if that fixes things also.

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 17:59, 19 June 23
@OffseT When i.e. RUN"/ABC" if not at the root, ABC will run, but if at the root, then ABC will fail with a message saying we are already at the root.  What that means is a BASIC program cannot run something always with the same code, sometimes it would need to be RUN"ABC" and sometimes RUN"/ABC".  I am thinking that RUN"/ABC" even if already at the root, should just run ABC.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 18:31, 19 June 23
Quote from: zhulien on 17:59, 19 June 23@OffseT When i.e. RUN"/ABC" if not at the root, ABC will run, but if at the root, then ABC will fail with a message saying we are already at the root.  What that means is a BASIC program cannot run something always with the same code, sometimes it would need to be RUN"ABC" and sometimes RUN"/ABC".  I am thinking that RUN"/ABC" even if already at the root, should just run ABC.

I'm not sure I understood your use case.

To sum-up everything:
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 21:41, 19 June 23
Quote from: OffseT on 18:31, 19 June 23
Quote from: zhulien on 17:59, 19 June 23@OffseT When i.e. RUN"/ABC" if not at the root, ABC will run, but if at the root, then ABC will fail with a message saying we are already at the root.  What that means is a BASIC program cannot run something always with the same code, sometimes it would need to be RUN"ABC" and sometimes RUN"/ABC".  I am thinking that RUN"/ABC" even if already at the root, should just run ABC.

I'm not sure I understood your use case.

To sum-up everything:
  • RUN"ABC" will always start ABC from the current directory.
  • RUN"/ABC" will always start ABC from the parent directory; if you are already at the root, it will fail since there is no parent.
  • RUN":ABC" will always start ABC from the root directory of the current drive (whatever the current directory is).

Thanks, I didn't know about :ABC, I was thinking more Unix or MSDOS with the / thinking / meant root, not parent
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 22:30, 19 June 23
Quote from: zhulien on 21:41, 19 June 23Thanks, I didn't know about :ABC, I was thinking more Unix or MSDOS with the / thinking / meant root, not parent
Nope, in fact '/' is only used for directories while ':' is used for root, making everything generic.
I never thought Unix or MS-DOS ways were good ones (actually I'm quite convinced they are bad ways :P).

DRIVE:PATH/FILE can then be read as "FILE from directory ( / ) PATH at root ( : ) of DRIVE".

UniDOS path handling scheme is explained here:
https://unidos.cpcscene.net/doku.php?id=en:manuel#paths_handling
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 04:33, 20 June 23
actually i patched protext to instead of run"DISC" to run":EMS" because the autoexec locks up as I have no physical floppy drive, I can at least control+enter whereever I am to launch it. 
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 18:15, 21 June 23
@OffseT 

Here is my first cut at coding the simplest DOS Node I can think of, it however doesn't appear to initialise - I am not ruling out bugs in the Node, but given the simplicity of it, perhaps you will know right away why it might not initialise as a node when performing a |drive function?  I am assembling direct to ROM space within Maxam within WinAPE.

The streamer is a write-only streamer with a single writer.  hmm, I will check my strcompare in CheckDrive - maybe something to do with me not ignoring Bit 7.

Org &c000

write direct -1,2,#C0

ROMType db 2; 1 (secondary ROM) or 2 (expansion ROM)

ROMMark db 1; It is customary that the version of a ROM
ROMVer db 4; is displayed in the form M VR
ROMRev db 1; (i.e. 1.00 here)

ROMRSX dw RSXTable

jp InitROM
jp DOSNode_Init ; implemented
jp DOSNode_CheckDrive ; implemented
jp DOSNode_GetStatus ; implemented
jp DOSNode_GetName ; implemented
jp DOSNode_GetDesc ; implemented
jp DOSNode_GetFreeSpace ; implemented
jp DOSNode_InOpenStream
jp DOSNode_InReadStream
jp DOSNode_InCloseStream
jp DOSNode_InSeekStream
jp DOSNode_OutOpenStream ; implemented
jp DOSNode_OutWriteStream ; implemented
jp DOSNode_OutCloseStream ; implemented
jp DOSNode_OutSeekStream
jp DOSNode_Examine
jp DOSNode_ExamineNext
jp DOSNode_Rename
jp DOSNode_Delete
jp DOSNode_CreateDir
jp DOSNode_SetProtection
jp DOSNode_Format
jp DOSNode_SetFileDate
jp DOSNode_Void
jp DOSNode_Void
jp DOSNode_Void
jp DOSNode_ReadRTC
jp DOSNode_WriteRTC
jp DOSNode_OpenNVRAM
jp DOSNode_CloseNVRAM
jp DOSNode_ReadNVRAM
jp DOSNode_WriteNVRAM
jp DOSNode_SeekNVRAM
; You can add your personal RSX here (if ROM type 1)

RSXTable
str "SCREEN STREAMER"
str "DOS Node"

db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80

; You can add your personal RSX here (if ROM type 1)
db 0; End of the RSX table

        ; Actual ROM code starts here
InitROM: cp a
ret

BYTES_FREE_HW equ #ffff ; high word
BYTES_FREE_LW equ #ffff ; low word
READER_COUNT equ 1 ; number of readers
TXT_OUT_CHAR equ #bb5a

DriveName: text "SCR"
db 0
DriveNameStr: text "SC"
db "R" + #80, 0
DriveNameDsc: text "Vorax Screen Streame"
db "r" + #80, 0

;
; Initialize the noeud DOS
;
; Input   - A = initialization status (see flags Init_*)
;               Bit0 = 1 if the CPC is doing a cold boot
;               Other bits are unused
; Output  - If Carry = 1 then the node was intialized
;               If Z then a non volatile memory handler is available in this node (2K mini)
;               If NZ then non voltile memory handler is not available
;                   A = error code
;           If Carry = 0 then the node could not be initialized
; Altered - AF

DOSNode_Init: jp DOSNode_Success

;
; Check if a drive name is handled by the DOS node
;
; Input   - HL = pointer to the drive name
;                (bit 7 could be set on some character and mush be ignored)
;           C = length of the drive name
; Output - If Carry = 1 a drive was found in the node
;                A = physical drive number
;           If Carry = 0 the drive was not found in the node
; Altered - AF

DOSNode_CheckDrive:
push de
push hl
ld de, DriveName
ex de, hl
call StrCompare
pop hl
pop de
jp nz, DOSNode_Fail

ld a, READER_COUNT
jp DOSNode_Success

;
; Return a drive status
;
; Input   - A = drive number
; Output  - If Carry = 1 a status was returned
;                A = status of the drive (see flags flags Media_*)
;                    Bit0 = 1 if a media is inserted in the drive
;                    Bit1 = 1 if the media support 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)
;                        $$$ and BAK filesis then disabled
;                    Bit5 = 1 if the media can be reached by the new UniDOS API
;                    Other bits are unused
;           If Carry = 0 then the drive is unknown and no status was returned
; Alteted - AF

DOSNode_GetStatus:
call ValidateReader
ret nc

ld a, %000010001
jp DOSNode_Success

;
; Return the name corresponding to a physical drive
;
; Input   - A = drive number
;           DE = address of a buffer of 8 bytes when to store the name
; Output  - If Carry = 1 the name was found
;                DE points to the first character after the end of the copied string
;                (the string is stored with the bit 7 of its last character set)
;          If Carry = 0 not description was found and the buffer is left unchanged.
; Altered - AF,DE

DOSNode_GetName:
call ValidateReader
ret nc

push hl
ld hl, DriveNameStr
call StrCopy
pop hl
jp DOSNode_Success

;
; Return the description corresponding to a physical drive
;
; Input  - A = drive number
;          DE = addess of the 32 bytes buffer where to store the description
; Ouput  - If Carry = 1 a description was found
;                DE points to the first character after the end of the copied string
;                (the string is stored with the bit 7 of its last character set)
;          If Carry = 0 not description was found and the buffer is left unchanged.
; Altered - AF,DE

DOSNode_GetDesc:
call ValidateReader
ret nc

push hl
ld hl, DriveNameDsc
call StrCopy
pop hl
jp DOSNode_Success

;
; Return the free space on a physical drive
;
; Input   - A = drive number
; Output  - If Carry = 1 the routine is supported for this drive
;                If Z then the free space could be obtained
;                    BCDE = free space in kilo-bytes
;                If NZ then an error occured
;                    A = error code
;           If Carry = 0 then the routines is invalid for this drive
; Altered - AF,BC,DE

DOSNode_GetFreeSpace:
call ValidateReader
ret nc

ld bc, BYTES_FREE_HW
ld de, BYTES_FREE_LW
xor a
jp DOSNode_Success

;
; Open the input stream
;
; Input   - A = drive number
;           HL = pointer to the normalized name
;               note, if the drive is of type stream then this name can
;               contain 11x&ff in case where no file name was provided
;               by the user (when he uses the anonymous reference ".");
;               the routine should then just open the just encountered
;               file on the stream and can optionally update the name
;               if it could be obtained from the stream itself
;          DE = pointer the normalized path
;          The pointed memory is always located in the current ROM/RAM space area
; Ouput  - If Carry = 1 the routine is supported for the provided drive
;                If Z then a file was opened
;                If NZ then no file could be opened
;                    A = error code
;               In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_InOpenStream:
jp DOSNode_Fail

;
; Read from the input stream
;
; Input  - A = drive number
;           HL = address where to stored the read data
;           DE = number of bytes to read
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then data could be read
;                    DE = number of bytes read
;                If NZ then a error occured
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF,DE

DOSNode_InReadStream:
jp DOSNode_Fail

;
; Close the input stream
;
; Input   - A = drive number
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the stream was properly closed
;                If NZ then the stream was closed with an error
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_InCloseStream:
jp DOSNode_Fail

;
; Change the position into the input stream
;
; Input   - A = drive number
;           DEHL = new position in the input stream
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the new position could be reached
;                If NZ then an error occured
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_InSeekStream:
jp DOSNode_Fail

;
; Open the output stream
;
; Input   - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;          The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then a file was created
;                If NZ then no file was created
;                    A = error code
;               In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_OutOpenStream:
call ValidateReader
ret nc

jp DOSNode_Success

;
; Write into the ouput stream
;
; Input   - A = drive number
;           HL = address where are located the data to write
;           DE = number of bytes to write
; Sortie - If Carry = 1 the routine is supported for the provided drive
;                If Z then data could be written
;                    DE = nomber of written bytes
;                If NZ then an error occured
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF,DE

DOSNode_OutWriteStream:
call ValidateReader
ret nc

push hl

DOSNode_OutWriteStreamLoop:
ld a, (hl)
call ValidateChar
jr nc, DOSNode_OutWriteStreamSkip

call TXT_OUT_CHAR

DOSNode_OutWriteStreamSkip:
inc hl
dec de

ld a,(de)
or e
jr nz, DOSNode_OutWriteStreamLoop

DOSNode_OutWriteStreamEnd:
pop hl
jp DOSNode_Success

;
; Close the output stream
;
; Input   - A = drive number
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the stream was properly closed
;                If NZ then the stream was closed with an error
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_OutCloseStream:
call ValidateReader
ret nc

jp DOSNode_Success

;
; Change the position into the output stream
;
; Input   - A = drive number
;           DEHL = new position in the ouput stream
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the new position could be reached
;                If NZ then an error occured
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_OutSeekStream:
jp DOSNode_Fail

;
; Check that a file or directory exists and return associated information
;
; Input   - A = drive number
;           HL = pointer to the normalized name
;               If HL = 0 then it is the contents of the directory which has to be analyzed
;               and ExamineNext will be called next to retrieve each entry
;           DE = pointer to the normalized path
;           IX = buffer where to store last modification time and date
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;
;                If HL was not 0 in input
;                    If Z then the file or directory exists
;                        A = protection bits of the file
;                            Bit 0 - Read-only
;                            Bit 1 - Hidden
;                            Bit 2 - System
;                            Bit 4 = Directory
;                            Bit 5 = Archived
;                        BCDE = Length of the file
;                        IX = buffer where last modification time and date of the entry were stored
;                            One 16-bit word with year (1978..9999)
;                            One byte with number of month (1..12)
;                            One byte with number of day in the month (1..28,29,30 or 31)
;                            One byte with hours (0..23)
;                            One byte with minutes (0..59)
;                            One byte with seconds (0..59)
;                    If NZ then the file or directory was not found
;                        A = error code
;
;                If HL was 0 in input
;                    If Z then the directory is ready to be examined through ExamineNext
;                    If NZ then an error occurred
;                        A = error code
;
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_Examine:
jp DOSNode_Fail

;
; Get the next entry from a directory being examined
;
; Input   - A = drive number
;           HL = pointer to the memory where to store the normalize name
;           IX = buffer where to store last modification time and date
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then an entry was found
;                    HL = pointer to the memory updated with the found normalized name
;                        A = protection bits of the file
;                            Bit 0 - Read-only
;                            Bit 1 - Hidden
;                            Bit 2 - System
;                            Bit 4 = Directory
;                            Bit 5 = Archived
;                        BCDE = Length of the file
;                        IX = buffer where last modification time and date of the entry were stored
;                            One 16-bit word with year (1978..9999)
;                            One byte with number of month (1..12)
;                            One byte with number of day in the month (1..28,29,30 or 31)
;                            One byte with hours (0..23)
;                            One byte with minutes (0..59)
;                            One byte with seconds (0..59)
;                If NZ then an error occurred
;                    A = error code (dsk_err_file_not_found indicates that all entries were examined)
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_ExamineNext:
jp DOSNode_Fail

;
; Rename a file or a directory
;
; Input   - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;           IX = pointer to the new normalized name
;           BC = pointer to the new normalized path
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the file or directory was renamed
;                If NZ then the file or directory could not be renamed
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_Rename: jp DOSNode_Fail

;
; Delete a file or a directory
;
; Input  - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the file or directory was deleted
;                If NZ then the file or directory could not be deleted
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_Delete: jp DOSNode_Fail

;
; Create a directory
;
; Input  - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the directory was created
;                If NZ then the directory could not be created
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_CreateDir:
jp DOSNode_Fail

;
; Change the protection bits of a file
;
; Input  - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;           B = Protections to modify
;           C = New protections
;                Bit 0 - Read-only
;                Bit 1 - Hidden
;                Bit 5 = Archived
;           Other bits are ignored
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the protections were modified
;                If NZ then the protections could not be modified
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_SetProtection:
jp DOSNode_Fail

;
; Change last modification time and date of a file or a directory
;
; Input  - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;           IX = buffer where last modification time and date to use for the entry are stored
;               One 16-bit word with year (1978..9999)
;               One byte with number of month (1..12)
;               One byte with number of day in the month (1..28,29,30 or 31)
;               One byte with hours (0..23)
;               One byte with minutes (0..59)
;               One byte with seconds (0..59)
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the time and date were modified
;                If NZ then the time and date could not be modified
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_SetFileDate:
jp DOSNode_Fail

;
; Format a drive
;
; Input  - A = drive number
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the drive was formatted
;                If NZ then format failed
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_Format: jp DOSNode_Fail

;
; Read the contents of the real time clock
;
; Input   - IX = buffer where to store current time and date (7 octets)
; Output  - If Carry = 1 the the DOS node handles a relax time clock
;                IX = buffer where current time and date were stored
;                    One 16-bit word with year (1978..9999)
;                    One byte with number of the month (1..12)
;                    One byte with the number of the day in the month (1..28,29,30 or 31)
;                    One byte with hours (0..23)
;                    One byte with minutes (0..59)
;                    One byte with seconds (0..59)
;                 A = number of the day in the week (1..7, from Monday to Sunday)
;           If Carry = 0 the the DOS node do not handle a real time clock
; Altered - AF

DOSNode_ReadRTC:
jp DOSNode_Fail

;
; Write into the real time clock
;
; Input   - IX = buffer containing time and date to write into real time clock (7 bytes)
;               One 16-bit word with year (1978..9999)
;               One byte with number of the month (1..12)
;               One byte with the number of the day in the month (1..28,29,30 or 31)
;               One byte with hours (0..23)
;               One byte with minutes (0..59)
;               One byte with seconds (0..59)
; Output  - If Carry = 1 then the DOS node handles a real time clock
;               If Z then the contents of the real time clock was updated
;               If NZ then an error occurred
;                   A = error code
;          If Carry = 1 then the DOS node do not handle a real time clock
; Altered - AF

DOSNode_WriteRTC:
jp DOSNode_Fail

;
; Open the non volatile memory
;
; Input  - C = opening mode
;                If 0 then the non volatile memory shall be opened with its current contents
;                If 1 then the non volatile memory shall be opened with its contents reset
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then the non volatile memory has been opened and is ready for usage
;                If NZ then a error occured
;                    A = error code
;           If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF

DOSNode_OpenNVRAM:
jp DOSNode_Fail

;
; Close and update the non volatile memory memory contents
;
; Input  - None
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then the non volatile memory was properly updated
;                If NZ then an error occured
;           If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF

DOSNode_CloseNVRAM:
jp DOSNode_Fail

;
; Read data from the non volatile memory
;
; Input  - HL = address where to write read data
;           DE = number of bytes to read
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then data were read
;                    DE = number of bytes read
;                If NZ then a error occured
;                    A = error code
;           If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF,DE

DOSNode_ReadNVRAM:
jp DOSNode_Fail

;
; Write data to the non volatile memory
;
; Input  - HL = address where a located data to write
;           DE = number of bytes to write
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then data were written
;                    DE = number of bytes written
;                If NZ then a error occured
;                    A = error code
;           If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF,DE

DOSNode_WriteNVRAM:
jp DOSNode_Fail

;
; Change the position in the non volatile memory
;
; Input  - DEHL = new position
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then the new position was reached
;                If NZ then a error occured
;                    A = error code
;           If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF,DE

DOSNode_SeekNVRAM:
jp DOSNode_Fail

DOSNode_Void: ret

DOSNode_Fail: ccf
ret

DOSNode_Success:
scf
ret

; ------------------------- StrCompare
; -- parameters:
; -- HL = zero terminated string source of truth
; -- DE = string to compare
; --
; -- return:
; -- Z if equal, NZ if not
; -- all other registers unknown

StrCompare:
ex de, hl

StrCompareLoop:
ld a, (de)
cp (hl)
ret nz ; false match return
or a
ret z ; end of string return
inc hl
inc de
jr StrCompareLoop

; ------------------------- StrCopy
; -- parameters:
; -- HL = source string address
; -- DE = destination string address
; --
; -- return:
; -- HL = the address of the source string terminator
; -- DE = the address of the destination string terminator
; -- all other registers unknown

StrCopy:
ld a,(hl)
ld (de), a
or a
ret z ; end of string return
inc hl
inc de
jr StrCopy

; ------------------------- ValidateReader
; -- parameters:
; -- A = reader to validate
; --
; -- return:
; -- C if valid, NC if not
; -- all other registers unknown

ValidateReader: push bc
ld b, a ; validate reader
ld a, READER_COUNT
cp b
jp c, ValidateReaderFail
pop bc
jp DOSNode_Success

ValidateReaderFail:
pop bc
jp DOSNode_Fail

; ------------------------- ValidateChar
; -- parameters:
; -- A = character to validate
; --
; -- return:
; -- C if valid, NC if not
; -- all other registers preserved

ValidateChar:
cp '0'
jr c, DOSNode_Fail

cp 'z'
jr nc, DOSNode_Fail

jp DOSNode_Success

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 18:21, 21 June 23
not relevant
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 18:24, 21 June 23
not relevant
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 19:22, 21 June 23
Modified to treat drives as zero-based assuming we will never have a zero drive node

Org &c000

write direct -1,2,#C0

ROMType db 2; 1 (secondary ROM) or 2 (expansion ROM)

ROMMark db 1; It is customary that the version of a ROM
ROMVer db 4; is displayed in the form M VR
ROMRev db 1; (i.e. 1.00 here)

ROMRSX dw RSXTable

jp InitROM
jp DOSNode_Init ; implemented
jp DOSNode_CheckDrive ; implemented
jp DOSNode_GetStatus ; implemented
jp DOSNode_GetName ; implemented
jp DOSNode_GetDesc ; implemented
jp DOSNode_GetFreeSpace ; implemented
jp DOSNode_InOpenStream
jp DOSNode_InReadStream
jp DOSNode_InCloseStream
jp DOSNode_InSeekStream
jp DOSNode_OutOpenStream ; implemented
jp DOSNode_OutWriteStream ; implemented
jp DOSNode_OutCloseStream ; implemented
jp DOSNode_OutSeekStream
jp DOSNode_Examine
jp DOSNode_ExamineNext
jp DOSNode_Rename
jp DOSNode_Delete
jp DOSNode_CreateDir
jp DOSNode_SetProtection
jp DOSNode_Format
jp DOSNode_SetFileDate
jp DOSNode_Void
jp DOSNode_Void
jp DOSNode_Void
jp DOSNode_ReadRTC
jp DOSNode_WriteRTC
jp DOSNode_OpenNVRAM
jp DOSNode_CloseNVRAM
jp DOSNode_ReadNVRAM
jp DOSNode_WriteNVRAM
jp DOSNode_SeekNVRAM
; You can add your personal RSX here (if ROM type 1)

RSXTable
str "SCREEN STREAMER"
str "DOS Node"

db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80

; You can add your personal RSX here (if ROM type 1)
db 0; End of the RSX table

        ; Actual ROM code starts here
InitROM: cp a
ret

BYTES_FREE_HW equ #ffff ; high word
BYTES_FREE_LW equ #ffff ; low word
READER_COUNT equ 1 ; number of readers
TXT_OUT_CHAR equ #bb5a

DriveName: text "SCR"
db 0
DriveNameNbr: db 0
DriveNameStr: text "SC"
db "R" + #80, 0
DriveNameDsc: text "Vorax Screen Streame"
db "r" + #80, 0

;
; Initialize the noeud DOS
;
; Input   - A = initialization status (see flags Init_*)
;               Bit0 = 1 if the CPC is doing a cold boot
;               Other bits are unused
; Output  - If Carry = 1 then the node was intialized
;               If Z then a non volatile memory handler is available in this node (2K mini)
;               If NZ then non voltile memory handler is not available
;                   A = error code
;           If Carry = 0 then the node could not be initialized
; Altered - AF

DOSNode_Init: ld a, 1
or a
jp DOSNode_Success

;
; Check if a drive name is handled by the DOS node
;
; Input   - HL = pointer to the drive name
;                (bit 7 could be set on some character and mush be ignored)
;           C = length of the drive name
; Output - If Carry = 1 a drive was found in the node
;                A = physical drive number
;           If Carry = 0 the drive was not found in the node
; Altered - AF

DOSNode_CheckDrive:
push de
push hl
ld de, DriveName
ex de, hl
call StrCompare
pop hl
pop de
jp nz, DOSNode_Fail

ld a, (DriveNameNbr)
jp DOSNode_Success

;
; Return a drive status
;
; Input   - A = drive number
; Output  - If Carry = 1 a status was returned
;                A = status of the drive (see flags flags Media_*)
;                    Bit0 = 1 if a media is inserted in the drive
;                    Bit1 = 1 if the media support 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)
;                        $$$ and BAK filesis then disabled
;                    Bit5 = 1 if the media can be reached by the new UniDOS API
;                    Other bits are unused
;           If Carry = 0 then the drive is unknown and no status was returned
; Alteted - AF

DOSNode_GetStatus:
call ValidateReader
ret nc

ld a, %000110001
jp DOSNode_Success

;
; Return the name corresponding to a physical drive
;
; Input   - A = drive number
;           DE = address of a buffer of 8 bytes when to store the name
; Output  - If Carry = 1 the name was found
;                DE points to the first character after the end of the copied string
;                (the string is stored with the bit 7 of its last character set)
;          If Carry = 0 not description was found and the buffer is left unchanged.
; Altered - AF,DE

DOSNode_GetName:
call ValidateReader
ret nc

push hl
ld hl, DriveNameStr
call StrCopy
pop hl
jp DOSNode_Success

;
; Return the description corresponding to a physical drive
;
; Input  - A = drive number
;          DE = addess of the 32 bytes buffer where to store the description
; Ouput  - If Carry = 1 a description was found
;                DE points to the first character after the end of the copied string
;                (the string is stored with the bit 7 of its last character set)
;          If Carry = 0 not description was found and the buffer is left unchanged.
; Altered - AF,DE

DOSNode_GetDesc:
call ValidateReader
ret nc

push hl
ld hl, DriveNameDsc
call StrCopy
pop hl
jp DOSNode_Success

;
; Return the free space on a physical drive
;
; Input   - A = drive number
; Output  - If Carry = 1 the routine is supported for this drive
;                If Z then the free space could be obtained
;                    BCDE = free space in kilo-bytes
;                If NZ then an error occured
;                    A = error code
;           If Carry = 0 then the routines is invalid for this drive
; Altered - AF,BC,DE

DOSNode_GetFreeSpace:
call ValidateReader
ret nc

ld bc, BYTES_FREE_HW
ld de, BYTES_FREE_LW
xor a
jp DOSNode_Success

;
; Open the input stream
;
; Input   - A = drive number
;           HL = pointer to the normalized name
;               note, if the drive is of type stream then this name can
;               contain 11x&ff in case where no file name was provided
;               by the user (when he uses the anonymous reference ".");
;               the routine should then just open the just encountered
;               file on the stream and can optionally update the name
;               if it could be obtained from the stream itself
;          DE = pointer the normalized path
;          The pointed memory is always located in the current ROM/RAM space area
; Ouput  - If Carry = 1 the routine is supported for the provided drive
;                If Z then a file was opened
;                If NZ then no file could be opened
;                    A = error code
;               In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_InOpenStream:
jp DOSNode_Fail

;
; Read from the input stream
;
; Input  - A = drive number
;           HL = address where to stored the read data
;           DE = number of bytes to read
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then data could be read
;                    DE = number of bytes read
;                If NZ then a error occured
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF,DE

DOSNode_InReadStream:
jp DOSNode_Fail

;
; Close the input stream
;
; Input   - A = drive number
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the stream was properly closed
;                If NZ then the stream was closed with an error
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_InCloseStream:
jp DOSNode_Fail

;
; Change the position into the input stream
;
; Input   - A = drive number
;           DEHL = new position in the input stream
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the new position could be reached
;                If NZ then an error occured
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_InSeekStream:
jp DOSNode_Fail

;
; Open the output stream
;
; Input   - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;          The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then a file was created
;                If NZ then no file was created
;                    A = error code
;               In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_OutOpenStream:
call ValidateReader
ret nc

jp DOSNode_Success

;
; Write into the ouput stream
;
; Input   - A = drive number
;           HL = address where are located the data to write
;           DE = number of bytes to write
; Sortie - If Carry = 1 the routine is supported for the provided drive
;                If Z then data could be written
;                    DE = nomber of written bytes
;                If NZ then an error occured
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF,DE

DOSNode_OutWriteStream:
call ValidateReader
ret nc

push hl

DOSNode_OutWriteStreamLoop:
ld a, (hl)
call ValidateChar
jr nc, DOSNode_OutWriteStreamSkip

call TXT_OUT_CHAR

DOSNode_OutWriteStreamSkip:
inc hl
dec de

ld a,(de)
or e
jr nz, DOSNode_OutWriteStreamLoop

DOSNode_OutWriteStreamEnd:
pop hl
jp DOSNode_Success

;
; Close the output stream
;
; Input   - A = drive number
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the stream was properly closed
;                If NZ then the stream was closed with an error
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_OutCloseStream:
call ValidateReader
ret nc

jp DOSNode_Success

;
; Change the position into the output stream
;
; Input   - A = drive number
;           DEHL = new position in the ouput stream
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the new position could be reached
;                If NZ then an error occured
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_OutSeekStream:
jp DOSNode_Fail

;
; Check that a file or directory exists and return associated information
;
; Input   - A = drive number
;           HL = pointer to the normalized name
;               If HL = 0 then it is the contents of the directory which has to be analyzed
;               and ExamineNext will be called next to retrieve each entry
;           DE = pointer to the normalized path
;           IX = buffer where to store last modification time and date
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;
;                If HL was not 0 in input
;                    If Z then the file or directory exists
;                        A = protection bits of the file
;                            Bit 0 - Read-only
;                            Bit 1 - Hidden
;                            Bit 2 - System
;                            Bit 4 = Directory
;                            Bit 5 = Archived
;                        BCDE = Length of the file
;                        IX = buffer where last modification time and date of the entry were stored
;                            One 16-bit word with year (1978..9999)
;                            One byte with number of month (1..12)
;                            One byte with number of day in the month (1..28,29,30 or 31)
;                            One byte with hours (0..23)
;                            One byte with minutes (0..59)
;                            One byte with seconds (0..59)
;                    If NZ then the file or directory was not found
;                        A = error code
;
;                If HL was 0 in input
;                    If Z then the directory is ready to be examined through ExamineNext
;                    If NZ then an error occurred
;                        A = error code
;
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_Examine:
jp DOSNode_Fail

;
; Get the next entry from a directory being examined
;
; Input   - A = drive number
;           HL = pointer to the memory where to store the normalize name
;           IX = buffer where to store last modification time and date
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then an entry was found
;                    HL = pointer to the memory updated with the found normalized name
;                        A = protection bits of the file
;                            Bit 0 - Read-only
;                            Bit 1 - Hidden
;                            Bit 2 - System
;                            Bit 4 = Directory
;                            Bit 5 = Archived
;                        BCDE = Length of the file
;                        IX = buffer where last modification time and date of the entry were stored
;                            One 16-bit word with year (1978..9999)
;                            One byte with number of month (1..12)
;                            One byte with number of day in the month (1..28,29,30 or 31)
;                            One byte with hours (0..23)
;                            One byte with minutes (0..59)
;                            One byte with seconds (0..59)
;                If NZ then an error occurred
;                    A = error code (dsk_err_file_not_found indicates that all entries were examined)
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_ExamineNext:
jp DOSNode_Fail

;
; Rename a file or a directory
;
; Input   - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;           IX = pointer to the new normalized name
;           BC = pointer to the new normalized path
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the file or directory was renamed
;                If NZ then the file or directory could not be renamed
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_Rename: jp DOSNode_Fail

;
; Delete a file or a directory
;
; Input  - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the file or directory was deleted
;                If NZ then the file or directory could not be deleted
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_Delete: jp DOSNode_Fail

;
; Create a directory
;
; Input  - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the directory was created
;                If NZ then the directory could not be created
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_CreateDir:
jp DOSNode_Fail

;
; Change the protection bits of a file
;
; Input  - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;           B = Protections to modify
;           C = New protections
;                Bit 0 - Read-only
;                Bit 1 - Hidden
;                Bit 5 = Archived
;           Other bits are ignored
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the protections were modified
;                If NZ then the protections could not be modified
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_SetProtection:
jp DOSNode_Fail

;
; Change last modification time and date of a file or a directory
;
; Input  - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;           IX = buffer where last modification time and date to use for the entry are stored
;               One 16-bit word with year (1978..9999)
;               One byte with number of month (1..12)
;               One byte with number of day in the month (1..28,29,30 or 31)
;               One byte with hours (0..23)
;               One byte with minutes (0..59)
;               One byte with seconds (0..59)
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the time and date were modified
;                If NZ then the time and date could not be modified
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_SetFileDate:
jp DOSNode_Fail

;
; Format a drive
;
; Input  - A = drive number
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the drive was formatted
;                If NZ then format failed
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_Format: jp DOSNode_Fail

;
; Read the contents of the real time clock
;
; Input   - IX = buffer where to store current time and date (7 octets)
; Output  - If Carry = 1 the the DOS node handles a relax time clock
;                IX = buffer where current time and date were stored
;                    One 16-bit word with year (1978..9999)
;                    One byte with number of the month (1..12)
;                    One byte with the number of the day in the month (1..28,29,30 or 31)
;                    One byte with hours (0..23)
;                    One byte with minutes (0..59)
;                    One byte with seconds (0..59)
;                 A = number of the day in the week (1..7, from Monday to Sunday)
;           If Carry = 0 the the DOS node do not handle a real time clock
; Altered - AF

DOSNode_ReadRTC:
jp DOSNode_Fail

;
; Write into the real time clock
;
; Input   - IX = buffer containing time and date to write into real time clock (7 bytes)
;               One 16-bit word with year (1978..9999)
;               One byte with number of the month (1..12)
;               One byte with the number of the day in the month (1..28,29,30 or 31)
;               One byte with hours (0..23)
;               One byte with minutes (0..59)
;               One byte with seconds (0..59)
; Output  - If Carry = 1 then the DOS node handles a real time clock
;               If Z then the contents of the real time clock was updated
;               If NZ then an error occurred
;                   A = error code
;          If Carry = 1 then the DOS node do not handle a real time clock
; Altered - AF

DOSNode_WriteRTC:
jp DOSNode_Fail

;
; Open the non volatile memory
;
; Input  - C = opening mode
;                If 0 then the non volatile memory shall be opened with its current contents
;                If 1 then the non volatile memory shall be opened with its contents reset
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then the non volatile memory has been opened and is ready for usage
;                If NZ then a error occured
;                    A = error code
;           If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF

DOSNode_OpenNVRAM:
jp DOSNode_Fail

;
; Close and update the non volatile memory memory contents
;
; Input  - None
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then the non volatile memory was properly updated
;                If NZ then an error occured
;           If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF

DOSNode_CloseNVRAM:
jp DOSNode_Fail

;
; Read data from the non volatile memory
;
; Input  - HL = address where to write read data
;           DE = number of bytes to read
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then data were read
;                    DE = number of bytes read
;                If NZ then a error occured
;                    A = error code
;           If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF,DE

DOSNode_ReadNVRAM:
jp DOSNode_Fail

;
; Write data to the non volatile memory
;
; Input  - HL = address where a located data to write
;           DE = number of bytes to write
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then data were written
;                    DE = number of bytes written
;                If NZ then a error occured
;                    A = error code
;           If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF,DE

DOSNode_WriteNVRAM:
jp DOSNode_Fail

;
; Change the position in the non volatile memory
;
; Input  - DEHL = new position
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then the new position was reached
;                If NZ then a error occured
;                    A = error code
;           If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF,DE

DOSNode_SeekNVRAM:
jp DOSNode_Fail

DOSNode_Void: ret

DOSNode_Fail: ccf
ret

DOSNode_Success:
scf
ret

; ------------------------- StrCompare
; -- parameters:
; -- HL = zero terminated string source of truth
; -- DE = string to compare
; --
; -- return:
; -- Z if equal, NZ if not
; -- all other registers unknown

StrCompare:
ex de, hl

StrCompareLoop:
ld a, (de)
and #7f

push af
ld a, (hl)
and #7f
ld b, a
pop af

cp b
ret nz ; false match return
or a
ret z ; end of string return
inc hl
inc de
jr StrCompareLoop

; ------------------------- StrCopy
; -- parameters:
; -- HL = source string address
; -- DE = destination string address
; --
; -- return:
; -- HL = the address of the source string terminator
; -- DE = the address of the destination string terminator
; -- all other registers unknown

StrCopy:
ld a,(hl)
ld (de), a
or a
ret z ; end of string return
inc hl
inc de
jr StrCopy

; ------------------------- ValidateReader
; -- parameters:
; -- A = reader to validate
; --
; -- return:
; -- C if valid, NC if not
; -- all other registers unknown

ValidateReader: push bc
ld b, a ; validate reader
ld a, READER_COUNT - 1
cp b
jp c, ValidateReaderFail
pop bc
jp DOSNode_Success

ValidateReaderFail:
pop bc
jp DOSNode_Fail

; ------------------------- ValidateChar
; -- parameters:
; -- A = character to validate
; --
; -- return:
; -- C if valid, NC if not
; -- all other registers preserved

ValidateChar:
cp '0'
jr c, DOSNode_Fail

cp 'z'
jr nc, DOSNode_Fail

jp DOSNode_Success
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 14:32, 22 June 23
Quote from: zhulien on 04:33, 20 June 23actually i patched protext to instead of run"DISC" to run":EMS" because the autoexec locks up as I have no physical floppy drive, I can at least control+enter whereever I am to launch it.
I guess you should be able to configure your HxC/Gotek firmware to conform with legacy Amstrad drives, so that it won't lock. I don't use HxC anymore, but AFAIK mine did not lock when accessed empty. It might be a matter of "Ready" (Amstrad/Amiga) vs "DiscChange" (PC) signal configuration.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 14:44, 22 June 23
Quote from: zhulien on 19:22, 21 June 23Modified to treat drives as zero-based assuming we will never have a zero drive node
By reading your code, I noticed that English documentation of Init was wrong. I just fixed the web site, sorry for that.

Here is the correct prototype:

;
; Initialize the DOS node
;
; Input  - A = initialization options (see input flags Init_*)
; Output - If Carry = 1 then the node was initialized
;              A = information about existing features (see output flags Init_*)
;          If Carry = 0 then the node could not be initialized
; Altered - AF

Does it help?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 18:03, 22 June 23
Thanks, what are the input and output flags for init_*

I couldn't find them anywhere

https://unidos.cpcscene.net/doku.php?id=en:n%C5%93ud_dos
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 20:42, 22 June 23
Quote from: zhulien on 18:03, 22 June 23Thanks, what are the input and output flags for init_*

I couldn't find them anywhere

https://unidos.cpcscene.net/doku.php?id=en:n%C5%93ud_dos
All UniDOS definitions are in SystemData.i file from UniDOS source code archive.

Here is an abstract:
;
; Flags for DOS nodes API
;

; Init bits
Init_ColdBoot_B     Equ 0   ; Input flag: DOS node is being initialized during a cold boot
Init_HaveNVRAM_B    Equ 5   ; Output flag: DOS node is providing non volatile memory
Init_HaveRTC_B      Equ 7   ; Output flag: DOS node is providing real time clock
; Init flags
Init_ColdBoot_F     Equ 1 << init_coldboot_b
Init_HaveNVRAM_F    Equ 1 << init_havenvram_b
Init_HaveRTC_F      Equ 1 << init_havertc_b

; Media bits
Media_Available_B   Equ 0
Media_HandleDir_B   Equ 1
Media_ReadOnly_B    Equ 2
Media_Removable_B   Equ 3
Media_StreamOnly_B  Equ 4
Media_NewAPI_B      Equ 5
Media_Formatable_B  Equ 6
; Media flags
Media_Available_F   Equ 1 << media_available_b
Media_HandleDir_F   Equ 1 << media_handledir_b
Media_ReadOnly_F    Equ 1 << media_readonly_b
Media_Removable_F   Equ 1 << media_removable_b
Media_StreamOnly_F  Equ 1 << media_streamonly_b
Media_NewAPI_F      Equ 1 << media_newapi_b
Media_Formatable_F  Equ 1 << media_formatable_b
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 00:56, 23 June 23
changing init to xor a; ret; had no difference at my end, still it shows as a dosnode when I |help, but doesn't show up in |drive

are there any other preconditions such as a node must be readable?  this is a write-only node.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 01:54, 23 June 23
debugging it appears something to do with drive numbers - what is that?  If my node e.g. has 8 drives, is that number referring to the drive in there?  Or is the drive number actually the node number?  i.e. I might be the 3rd node?  Which call is made to my node to find out how many drives I have anyway?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 02:26, 23 June 23
nope: it was my compare function... thanks for your help

The number to the right of implemented is the order of being called for future reference to others.  It seems it uses GetName to work out what device names are avaialble within the node and then it can focus future calls based on the results of the original iteration of GetName.

            jp DOSNode_Init            ; implemented, 1: called once, A = 1
            jp DOSNode_CheckDrive      ; implemented, 3: called once, HL = Streamer, Return 0
            jp DOSNode_GetStatus              ; implemented, 4: called once, A = 0
            jp DOSNode_GetName         ; implemented, 2: called 8 times, A = 0 to 7
            jp DOSNode_GetDesc         ; implemented, 6: called once, A = 0
            jp DOSNode_GetFreeSpace      ; implemented, 5: called once, A = 0

Another Note: if we don't compare string with case insensitivity, we get a bad command with the wrong case.

I now have a (mostly) working DOSNODE and can continue on with it.
If I do a cat on a write only DOS node, I get a Bad Command.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 06:02, 23 June 23
Here is an oddity...

I have added 4 devices to my node.  The names and descriptions search correctly and I believe return the flags correctly.  However when I |Drive, my DOSNode_GetDesc is called 7 times, first... 1, 2, 3, 4 (which are for my Node Names), then... 3 more times with 0, 0, 0 for DFA, DFB and TAPE.

Am I supposed to eliminate other devices from calling my node's GetDesc or is there some other thing that is supposed to stop My Description from showing against those 3 nodes?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 08:38, 23 June 23

UniDOS will ask for a description for each drive of the node that indicated an inserted media.

IIRC, calling sequence should be something like that:
GetStatus (for each 0-7 drive from the DOS node), and if both Carry and media inserted bit are set, then GetName & GetDesc.

Anycase, your node shall only set carry for drive numbers it handles. Reply NC otherwise.

You should also double check that your routines do not modify some forbidden registers (only the ones listed as "altered" can be). Modifying unexpected registers could break UniDOS. For performance and memory saving reasons UniDOS does not push/pop its registers when calling a DOS node routine.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 10:04, 23 June 23
hmm, GetName is called 8 times, I return C for 6 (now as I have 6 drives), and 2 NC.  Then it calls GetDesc not only for my 6 drives, but also for the 3 drives that are not even related to my Node.

I have attached my code here if you would like to have a play, it has 4 nodes coded - 2 tested (VDU (screen) & DACA (amdrum)).  DACM (music machine) and PRN (printer) I have no printer to test with, and no emulators are working with music machine so I guessed - yet to try the node on my real hardware.  SPCHA (SSA1) and SPCHD (DkTronics) yet to code the write routine.

I had a couple of thoughts wouldn't mind your feedback.  There are only 8 devices in a Node, of course we can have lots of nodes, but these won't take lots of ROM storage so a waste to not support more than 8 devices over time.  Rather than me making lots of devices, I was thinking to make a single device for each category, and a path for the actual things to write to.  eg: PRN for all printers, inside that a virtual folder INTERNAL.  SPCH for all speech synth, inside that SSA1 and DKTRONIC virtual folders.  DACS for all DACs, inside virtual folders AMDRUM and MMACHINE.  Of course instead of SPCH and DACS devices, I could just have AUDIO and put SSA1, DKTRONIC, AMDRUM, MMACHINE all in there?

What do you think is best for future expansion for such streams.  If different folders, then I can read from them too to get device statistics or configure them too, like payback speed by writing to a file in a virtual folder.

Future copy commands that honor unidos correctly will also be e.g. able to copy a text file from a disc, to screen to output it... or to the printer to print it... or to SSA1 to speak it.

org #c000

;write direct #C000, #0a

CODE_START:

ROMType db 2; 1 (secondary ROM) or 2 (expansion ROM)

ROMMark db 1; It is customary that the version of a ROM
ROMVer db 4; is displayed in the form M VR
ROMRev db 1; (i.e. 1.00 here)

ROMRSX dw RSXTable

jp InitROM
jp DOSNode_Init ; implemented, 1: called once, A = 1
jp DOSNode_CheckDrive ; implemented, 3: called once, HL = Streamer, Return 0
jp DOSNode_GetStatus ; implemented, 4: called once, A = 0
jp DOSNode_GetName ; implemented, 2: called 8 times, A = 0 to 7
jp DOSNode_GetDesc ; implemented, 6: called once, A = 0
jp DOSNode_GetFreeSpace ; implemented, 5: called once, A = 0
jp DOSNode_InOpenStream
jp DOSNode_InReadStream
jp DOSNode_InCloseStream
jp DOSNode_InSeekStream
jp DOSNode_OutOpenStream ; implemented
jp DOSNode_OutWriteStream ; implemented
jp DOSNode_OutCloseStream ; implemented
jp DOSNode_OutSeekStream
jp DOSNode_Examine
jp DOSNode_ExamineNext
jp DOSNode_Rename
jp DOSNode_Delete
jp DOSNode_CreateDir
jp DOSNode_SetProtection
jp DOSNode_Format
jp DOSNode_SetFileDate
jp DOSNode_Void
jp DOSNode_Void
jp DOSNode_Void
jp DOSNode_ReadRTC
jp DOSNode_WriteRTC
jp DOSNode_OpenNVRAM
jp DOSNode_CloseNVRAM
jp DOSNode_ReadNVRAM
jp DOSNode_WriteNVRAM
jp DOSNode_SeekNVRAM
; You can add your personal RSX here (if ROM type 1)

RSXTable
str "STREAMER"
str "DOS Node"

db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80
db #80

; You can add your personal RSX here (if ROM type 1)
db 0; End of the RSX table

        ; Actual ROM code starts here
InitROM: cp a
ret

BYTES_FREE_HW equ #00ff ; high word
BYTES_FREE_LW equ #ffff ; low word
DAC_DELAY equ 4 ; slow dac playing a bit
PORT_DACA equ #ff
PORT_DACM equ #f8f0

MC_PRINT_CHAR equ #bd2b
TXT_OUT_CHAR equ #bb5a

Drive_VDU equ #0
Drive_PRN equ #1
Drive_DACA equ #2 ; AMDRUM DAC
Drive_DACM equ #3 ; Music Machine DAC
Drive_SPCHA equ #4 ; Amstrad SSA-1 Speech Synth
Drive_SPCHD equ #5 ; Dk'Tronics Speech Synth

DriveNames:
DriveNameVDU: db "VD", "U" + #80, 0, Drive_VDU
DriveNamePRN: db "PR", "N" + #80, 0, Drive_PRN
DriveNameDACA: db "DAC", "A" + #80, 0, Drive_DACA
DriveNameDACM: db "DAC", "M" + #80, 0, Drive_DACM
DriveNameSPCHA: db "SPCH", "A" + #80, 0, Drive_SPCHA
DriveNameSPCHD: db "SPCH", "D" + #80, 0, Drive_SPCHD
db 0

DriveDescVDU: db "Text To Scree", "n" + #80, 0
DriveDescPRN: db "Standard Printer Por", "t" + #80, 0
DriveDescDACA: db "DAC Cheetah Amdru", "m" + #80, 0
DriveDescDACM: db "DAC RAM Music Machin", "e" + #80, 0
DriveDescSPCHA: db "Speech Amstra", "d" + #80, 0
DriveDescSPCHD: db "Speech Dk'tronic", "s" + #80, 0

;
; Initialize the noeud DOS
;
; Input   - A = initialization status (see flags Init_*)
;               Bit0 = 1 if the CPC is doing a cold boot
;               Other bits are unused
; Output  - If Carry = 1 then the node was intialized
;           If Carry = 0 then the node could not be initialized
; Altered - AF

DOSNode_Init: xor a
jp DOSNode_Success

;
; Check if a drive name is handled by the DOS node
;
; Input   - HL = pointer to the drive name
;                (bit 7 could be set on some character and mush be ignored)
;           C = length of the drive name
; Output - If Carry = 1 a drive was found in the node
;                A = physical drive number
;           If Carry = 0 the drive was not found in the node
; Altered - AF

DOSNode_CheckDrive:
push de
push hl
ld de, DriveNames
ex de, hl
call ListGetIDByName
pop hl
pop de
jp nz, DOSNode_Fail

jp DOSNode_Success

;
; Return a drive status
;
; Input   - A = drive number
; Output  - If Carry = 1 a status was returned
;                A = status of the drive (see flags flags Media_*)
;                    Bit0 = 1 if a media is inserted in the drive
;                    Bit1 = 1 if the media support 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)
;                        $$$ and BAK filesis then disabled
;                    Bit5 = 1 if the media can be reached by the new UniDOS API
;                    Other bits are unused
;           If Carry = 0 then the drive is unknown and no status was returned
; Alteted - AF

DOSNode_GetStatus:
cp Drive_VDU
jr z, DOSNode_GetStatus_VDU

cp Drive_PRN
jr z, DOSNode_GetStatus_PRN

cp Drive_DACA
jr z, DOSNode_GetStatus_DACA

cp Drive_DACM
jr z, DOSNode_GetStatus_DACM

cp Drive_SPCHA
jr z, DOSNode_GetStatus_SPCHA

cp Drive_SPCHD
jr z, DOSNode_GetStatus_SPCHD

jp DOSNode_Fail

DOSNode_GetStatus_VDU:
DOSNode_GetStatus_PRN:
DOSNode_GetStatus_DACA:
DOSNode_GetStatus_DACM:
DOSNode_GetStatus_SPCHA:
DOSNode_GetStatus_SPCHD:
ld a, %000110001
jp DOSNode_Success

;
; Return the name corresponding to a physical drive
;
; Input   - A = drive number
;           DE = address of a buffer of 8 bytes when to store the name
; Output  - If Carry = 1 the name was found
;                DE points to the first character after the end of the copied string
;                (the string is stored with the bit 7 of its last character set)
;          If Carry = 0 not description was found and the buffer is left unchanged.
; Altered - AF,DE

DOSNode_GetName:
cp Drive_VDU
jr z, DOSNode_GetName_VDU

cp Drive_PRN
jr z, DOSNode_GetName_PRN

cp Drive_DACA
jr z, DOSNode_GetName_DACA

cp Drive_DACM
jr z, DOSNode_GetName_DACM

cp Drive_SPCHA
jr z, DOSNode_GetName_SPCHA

cp Drive_SPCHD
jr z, DOSNode_GetName_SPCHD

jp DOSNode_Fail

DOSNode_GetName_VDU:
push hl
ld hl, DriveNameVDU
call StrCopy
pop hl
jp DOSNode_Success

DOSNode_GetName_PRN:
push hl
ld hl, DriveNamePRN
call StrCopy
pop hl
jp DOSNode_Success

DOSNode_GetName_DACA:
push hl
ld hl, DriveNameDACA
call StrCopy
pop hl
jp DOSNode_Success

DOSNode_GetName_DACM:
push hl
ld hl, DriveNameDACM
call StrCopy
pop hl
jp DOSNode_Success

DOSNode_GetName_SPCHA:
push hl
ld hl, DriveNameSPCHA
call StrCopy
pop hl
jp DOSNode_Success

DOSNode_GetName_SPCHD:
push hl
ld hl, DriveNameSPCHD
call StrCopy
pop hl
jp DOSNode_Success

;
; Return the description corresponding to a physical drive
;
; Input  - A = drive number
;          DE = addess of the 32 bytes buffer where to store the description
; Ouput  - If Carry = 1 a description was found
;                DE points to the first character after the end of the copied string
;                (the string is stored with the bit 7 of its last character set)
;          If Carry = 0 not description was found and the buffer is left unchanged.
; Altered - AF,DE

DOSNode_GetDesc:
cp Drive_VDU
jr z, DOSNode_GetDesc_VDU

cp Drive_PRN
jr z, DOSNode_GetDesc_PRN

cp Drive_DACA
jr z, DOSNode_GetDesc_DACA

cp Drive_DACM
jr z, DOSNode_GetDesc_DACM

cp Drive_SPCHA
jr z, DOSNode_GetDesc_SPCHA

cp Drive_SPCHD
jr z, DOSNode_GetDesc_SPCHD

jp DOSNode_Fail

DOSNode_GetDesc_VDU:
push hl
ld hl, DriveDescVDU
call StrCopy
pop hl
jp DOSNode_Success

DOSNode_GetDesc_PRN:
push hl
ld hl, DriveDescPRN
call StrCopy
pop hl
jp DOSNode_Success

DOSNode_GetDesc_DACA:
push hl
ld hl, DriveDescDACA
call StrCopy
pop hl
jp DOSNode_Success

DOSNode_GetDesc_DACM:
push hl
ld hl, DriveDescDACM
call StrCopy
pop hl
jp DOSNode_Success

DOSNode_GetDesc_SPCHA:
push hl
ld hl, DriveDescSPCHA
call StrCopy
pop hl
jp DOSNode_Success

DOSNode_GetDesc_SPCHD:
push hl
ld hl, DriveDescSPCHD
call StrCopy
pop hl
jp DOSNode_Success

;
; Return the free space on a physical drive
;
; Input   - A = drive number
; Output  - If Carry = 1 the routine is supported for this drive
;                If Z then the free space could be obtained
;                    BCDE = free space in kilo-bytes
;                If NZ then an error occured
;                    A = error code
;           If Carry = 0 then the routines is invalid for this drive
; Altered - AF,BC,DE

DOSNode_GetFreeSpace:
cp Drive_VDU
jr z, DOSNode_GetFreeSpace_VDU

cp Drive_PRN
jr z, DOSNode_GetFreeSpace_PRN

cp Drive_DACA
jr z, DOSNode_GetFreeSpace_DACA

cp Drive_DACM
jr z, DOSNode_GetFreeSpace_DACM

cp Drive_SPCHA
jr z, DOSNode_GetFreeSpace_SPCHA

cp Drive_SPCHD
jr z, DOSNode_GetFreeSpace_SPCHD

jp DOSNode_Fail

DOSNode_GetFreeSpace_VDU:
DOSNode_GetFreeSpace_PRN:
DOSNode_GetFreeSpace_DACA:
DOSNode_GetFreeSpace_DACM:
DOSNode_GetFreeSpace_SPCHA:
DOSNode_GetFreeSpace_SPCHD:
ld bc, BYTES_FREE_HW
ld de, BYTES_FREE_LW
xor a
jp DOSNode_Success

;
; Open the input stream
;
; Input   - A = drive number
;           HL = pointer to the normalized name
;               note, if the drive is of type stream then this name can
;               contain 11x&ff in case where no file name was provided
;               by the user (when he uses the anonymous reference ".");
;               the routine should then just open the just encountered
;               file on the stream and can optionally update the name
;               if it could be obtained from the stream itself
;          DE = pointer the normalized path
;          The pointed memory is always located in the current ROM/RAM space area
; Ouput  - If Carry = 1 the routine is supported for the provided drive
;                If Z then a file was opened
;                If NZ then no file could be opened
;                    A = error code
;               In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_InOpenStream:
jp DOSNode_Fail

;
; Read from the input stream
;
; Input  - A = drive number
;           HL = address where to stored the read data
;           DE = number of bytes to read
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then data could be read
;                    DE = number of bytes read
;                If NZ then a error occured
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF,DE

DOSNode_InReadStream:
jp DOSNode_Fail

;
; Close the input stream
;
; Input   - A = drive number
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the stream was properly closed
;                If NZ then the stream was closed with an error
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_InCloseStream:
jp DOSNode_Fail

;
; Change the position into the input stream
;
; Input   - A = drive number
;           DEHL = new position in the input stream
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the new position could be reached
;                If NZ then an error occured
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_InSeekStream:
jp DOSNode_Fail

;
; Open the output stream
;
; Input   - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;          The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then a file was created
;                If NZ then no file was created
;                    A = error code
;               In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_OutOpenStream:
cp Drive_VDU
jr z, DOSNode_OutOpenStream_VDU

cp Drive_PRN
jr z, DOSNode_OutOpenStream_PRN

cp Drive_DACA
jr z, DOSNode_OutOpenStream_DACA

cp Drive_DACM
jr z, DOSNode_OutOpenStream_DACM

cp Drive_SPCHA
jr z, DOSNode_OutOpenStream_SPCHA

cp Drive_SPCHD
jr z, DOSNode_OutOpenStream_SPCHD

jp DOSNode_Fail

DOSNode_OutOpenStream_VDU:
DOSNode_OutOpenStream_PRN:
DOSNode_OutOpenStream_DACA:
DOSNode_OutOpenStream_DACM:
DOSNode_OutOpenStream_SPCHA:
DOSNode_OutOpenStream_SPCHD:
jp DOSNode_Success

;
; Write into the ouput stream
;
; Input   - A = drive number
;           HL = address where are located the data to write
;           DE = number of bytes to write
; Sortie - If Carry = 1 the routine is supported for the provided drive
;                If Z then data could be written
;                    DE = nomber of written bytes
;                If NZ then an error occured
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF,DE

DOSNode_OutWriteStream:
cp Drive_VDU
jr z, DOSNode_OutWriteStream_VDU

cp Drive_PRN
jr z, DOSNode_OutWriteStream_PRN

cp Drive_DACA
jr z, DOSNode_OutWriteStream_DACA

cp Drive_DACM
jr z, DOSNode_OutWriteStream_DACM

cp Drive_SPCHA
jr z, DOSNode_OutWriteStream_SPCHA

cp Drive_SPCHD
jr z, DOSNode_OutWriteStream_SPCHD

jp DOSNode_Fail

; ----------------------------------------

DOSNode_OutWriteStream_VDU:

push hl

DOSNode_OutWriteStream_VDULoop:
ld a, (hl)
call ValidateChar
jr nc, DOSNode_OutWriteStream_VDUSkip

call TXT_OUT_CHAR

DOSNode_OutWriteStream_VDUSkip:
inc hl
dec de

ld a,d
or e
jr nz, DOSNode_OutWriteStream_VDULoop

DOSNode_OutWriteStream_VDUEnd:
pop hl
jp DOSNode_Success

; ----------------------------------------

DOSNode_OutWriteStream_PRN:

push hl

DOSNode_OutWriteStream_PRNLoop:
ld a, (hl)
;call ValidateChar
;jr nc, DOSNode_OutWriteStream_PRNSkip

call MC_PRINT_CHAR

;DOSNode_OutWriteStream_PRNSkip:
inc hl
dec de

ld a,d
or e
jr nz, DOSNode_OutWriteStream_PRNLoop

DOSNode_OutWriteStream_PRNEnd:
pop hl
jp DOSNode_Success

; ----------------------------------------

DOSNode_OutWriteStream_DACA:

push hl
push bc
di

DOSNode_OutWriteStream_DACALoop:

ld b, DAC_DELAY

DOSNode_OutWriteStream_DACALoop2:

push bc

ld c, (hl)
ld b, PORT_DACA
out (c), c

pop bc
djnz DOSNode_OutWriteStream_DACALoop2

inc hl
dec de

ld a,d
or e
jr nz, DOSNode_OutWriteStream_DACALoop

DOSNode_OutWriteStream_DACAEnd:
ei
pop bc
pop hl
jp DOSNode_Success

; ----------------------------------------

DOSNode_OutWriteStream_DACM:

push hl
push bc
di

DOSNode_OutWriteStream_DACMLoop:

ld b, DAC_DELAY

DOSNode_OutWriteStream_DACMLoop2:

push bc

ld a, (hl)
ld bc, PORT_DACM
out (c), a

pop bc
djnz DOSNode_OutWriteStream_DACMLoop2

inc hl
dec de

ld a,d
or e
jr nz, DOSNode_OutWriteStream_DACMLoop

DOSNode_OutWriteStream_DACMEnd:
ei
pop bc
pop hl
jp DOSNode_Success

; ----------------------------------------

DOSNode_OutWriteStream_SPCHA:

jp DOSNode_Success

; ----------------------------------------

DOSNode_OutWriteStream_SPCHD:

jp DOSNode_Success

;
; Close the output stream
;
; Input   - A = drive number
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the stream was properly closed
;                If NZ then the stream was closed with an error
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_OutCloseStream:
cp Drive_VDU
jr z, DOSNode_OutCloseStream_VDU

cp Drive_PRN
jr z, DOSNode_OutCloseStream_PRN

cp Drive_DACA
jr z, DOSNode_OutCloseStream_DACA

cp Drive_DACM
jr z, DOSNode_OutCloseStream_DACM

cp Drive_SPCHA
jr z, DOSNode_OutCloseStream_SPCHA

cp Drive_SPCHD
jr z, DOSNode_OutCloseStream_SPCHD

jp DOSNode_Fail

DOSNode_OutCloseStream_VDU:
DOSNode_OutCloseStream_PRN:
DOSNode_OutCloseStream_DACA:
DOSNode_OutCloseStream_DACM:
DOSNode_OutCloseStream_SPCHA:
DOSNode_OutCloseStream_SPCHD:
jp DOSNode_Success

;
; Change the position into the output stream
;
; Input   - A = drive number
;           DEHL = new position in the ouput stream
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the new position could be reached
;                If NZ then an error occured
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_OutSeekStream:
jp DOSNode_Fail

;
; Check that a file or directory exists and return associated information
;
; Input   - A = drive number
;           HL = pointer to the normalized name
;               If HL = 0 then it is the contents of the directory which has to be analyzed
;               and ExamineNext will be called next to retrieve each entry
;           DE = pointer to the normalized path
;           IX = buffer where to store last modification time and date
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;
;                If HL was not 0 in input
;                    If Z then the file or directory exists
;                        A = protection bits of the file
;                            Bit 0 - Read-only
;                            Bit 1 - Hidden
;                            Bit 2 - System
;                            Bit 4 = Directory
;                            Bit 5 = Archived
;                        BCDE = Length of the file
;                        IX = buffer where last modification time and date of the entry were stored
;                            One 16-bit word with year (1978..9999)
;                            One byte with number of month (1..12)
;                            One byte with number of day in the month (1..28,29,30 or 31)
;                            One byte with hours (0..23)
;                            One byte with minutes (0..59)
;                            One byte with seconds (0..59)
;                    If NZ then the file or directory was not found
;                        A = error code
;
;                If HL was 0 in input
;                    If Z then the directory is ready to be examined through ExamineNext
;                    If NZ then an error occurred
;                        A = error code
;
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_Examine:
jp DOSNode_Fail

;
; Get the next entry from a directory being examined
;
; Input   - A = drive number
;           HL = pointer to the memory where to store the normalize name
;           IX = buffer where to store last modification time and date
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then an entry was found
;                    HL = pointer to the memory updated with the found normalized name
;                        A = protection bits of the file
;                            Bit 0 - Read-only
;                            Bit 1 - Hidden
;                            Bit 2 - System
;                            Bit 4 = Directory
;                            Bit 5 = Archived
;                        BCDE = Length of the file
;                        IX = buffer where last modification time and date of the entry were stored
;                            One 16-bit word with year (1978..9999)
;                            One byte with number of month (1..12)
;                            One byte with number of day in the month (1..28,29,30 or 31)
;                            One byte with hours (0..23)
;                            One byte with minutes (0..59)
;                            One byte with seconds (0..59)
;                If NZ then an error occurred
;                    A = error code (dsk_err_file_not_found indicates that all entries were examined)
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_ExamineNext:
jp DOSNode_Fail

;
; Rename a file or a directory
;
; Input   - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;           IX = pointer to the new normalized name
;           BC = pointer to the new normalized path
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the file or directory was renamed
;                If NZ then the file or directory could not be renamed
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_Rename: jp DOSNode_Fail

;
; Delete a file or a directory
;
; Input  - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the file or directory was deleted
;                If NZ then the file or directory could not be deleted
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_Delete: jp DOSNode_Fail

;
; Create a directory
;
; Input  - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the directory was created
;                If NZ then the directory could not be created
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_CreateDir:
jp DOSNode_Fail

;
; Change the protection bits of a file
;
; Input  - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;           B = Protections to modify
;           C = New protections
;                Bit 0 - Read-only
;                Bit 1 - Hidden
;                Bit 5 = Archived
;           Other bits are ignored
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the protections were modified
;                If NZ then the protections could not be modified
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_SetProtection:
jp DOSNode_Fail

;
; Change last modification time and date of a file or a directory
;
; Input  - A = drive number
;           HL = pointer to the normalized name
;           DE = pointer to the normalized path
;           IX = buffer where last modification time and date to use for the entry are stored
;               One 16-bit word with year (1978..9999)
;               One byte with number of month (1..12)
;               One byte with number of day in the month (1..28,29,30 or 31)
;               One byte with hours (0..23)
;               One byte with minutes (0..59)
;               One byte with seconds (0..59)
;           The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the time and date were modified
;                If NZ then the time and date could not be modified
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_SetFileDate:
jp DOSNode_Fail

;
; Format a drive
;
; Input  - A = drive number
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the drive was formatted
;                If NZ then format failed
;                    A = error code
;           If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_Format: jp DOSNode_Fail

;
; Read the contents of the real time clock
;
; Input   - IX = buffer where to store current time and date (7 octets)
; Output  - If Carry = 1 the the DOS node handles a relax time clock
;                IX = buffer where current time and date were stored
;                    One 16-bit word with year (1978..9999)
;                    One byte with number of the month (1..12)
;                    One byte with the number of the day in the month (1..28,29,30 or 31)
;                    One byte with hours (0..23)
;                    One byte with minutes (0..59)
;                    One byte with seconds (0..59)
;                 A = number of the day in the week (1..7, from Monday to Sunday)
;           If Carry = 0 the the DOS node do not handle a real time clock
; Altered - AF

DOSNode_ReadRTC:
jp DOSNode_Fail

;
; Write into the real time clock
;
; Input   - IX = buffer containing time and date to write into real time clock (7 bytes)
;               One 16-bit word with year (1978..9999)
;               One byte with number of the month (1..12)
;               One byte with the number of the day in the month (1..28,29,30 or 31)
;               One byte with hours (0..23)
;               One byte with minutes (0..59)
;               One byte with seconds (0..59)
; Output  - If Carry = 1 then the DOS node handles a real time clock
;               If Z then the contents of the real time clock was updated
;               If NZ then an error occurred
;                   A = error code
;          If Carry = 1 then the DOS node do not handle a real time clock
; Altered - AF

DOSNode_WriteRTC:
jp DOSNode_Fail

;
; Open the non volatile memory
;
; Input  - C = opening mode
;                If 0 then the non volatile memory shall be opened with its current contents
;                If 1 then the non volatile memory shall be opened with its contents reset
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then the non volatile memory has been opened and is ready for usage
;                If NZ then a error occured
;                    A = error code
;           If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF

DOSNode_OpenNVRAM:
jp DOSNode_Fail

;
; Close and update the non volatile memory memory contents
;
; Input  - None
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then the non volatile memory was properly updated
;                If NZ then an error occured
;           If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF

DOSNode_CloseNVRAM:
jp DOSNode_Fail

;
; Read data from the non volatile memory
;
; Input  - HL = address where to write read data
;           DE = number of bytes to read
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then data were read
;                    DE = number of bytes read
;                If NZ then a error occured
;                    A = error code
;           If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF,DE

DOSNode_ReadNVRAM:
jp DOSNode_Fail

;
; Write data to the non volatile memory
;
; Input  - HL = address where a located data to write
;           DE = number of bytes to write
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then data were written
;                    DE = number of bytes written
;                If NZ then a error occured
;                    A = error code
;           If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF,DE

DOSNode_WriteNVRAM:
jp DOSNode_Fail

;
; Change the position in the non volatile memory
;
; Input  - DEHL = new position
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then the new position was reached
;                If NZ then a error occured
;                    A = error code
;           If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF,DE

DOSNode_SeekNVRAM:
jp DOSNode_Fail

DOSNode_Void: ret

DOSNode_Fail: ccf
ret

DOSNode_Success:
scf
ret

; ------------------------- ListGetIDByName
; -- parameters:
; -- HL = address of list to find a string within
; -- DE = string to find
; --
; -- return:
; -- Z if found, NZ if not
; -- A = entry number of found item
; -- all other registers unknown

ListGetIDByName:
ld a, (hl)
or a
jr z, ListGetIDByNameNotFound

push de
push hl
call StrCompare
pop hl
call StrSkip
pop de

jr z, ListGetIDByNameFound

inc hl
inc hl
jr ListGetIDByName

ListGetIDByNameFound:
inc hl
ld a, (hl)
ret

ListGetIDByNameNotFound:
xor a
ret

; ------------------------- StrCompare
; -- parameters:
; -- HL = zero terminated string source of truth
; -- DE = string to compare
; --
; -- return:
; -- Z if equal, NZ if not
; -- all other registers unknown

StrCompare:
StrCompareLoop:
ld a, (hl)
or a
ret z ; found it, return

call ToUpper
and #7f

push af
ld a, (de)
call ToUpper
and #7f
ld b, a
pop af

cp b
ret nz ; didnt find it, return
inc hl
inc de
jr StrCompareLoop

; ------------------------- ToUpper
; -- parameters:
; -- A = character to make into uppercase
; --
; -- return:
; -- A = uppercase character
; -- all other registers preserved except flags

ToUpper: cp 'a'
ret c
cp 'z' + 1
ret nc
add a, 'A' - 'a'
ret

; ------------------------- StrCopy
; -- parameters:
; -- HL = source string address
; -- DE = destination string address
; --
; -- return:
; -- HL = the address of the source string terminator
; -- DE = the address of the destination string terminator
; -- all other registers unknown

StrCopy:
ld a,(hl)
ld (de), a
or a
ret z ; end of string return
inc hl
inc de
jr StrCopy

StrSkip: push af

StrSkipLoop:
ld a,(hl)
or a
jr z, StrSkipEnd
inc hl
jr StrSkipLoop

StrSkipEnd: pop af
ret

; ------------------------- ValidateChar
; -- parameters:
; -- A = character to validate
; --
; -- return:
; -- C if valid, NC if not
; -- all other registers preserved

ValidateChar:
cp ' '
jr c, DOSNode_Fail

cp 'z'
jr nc, DOSNode_Fail

jp DOSNode_Success

CODE_END: ; ds #4000 - (CODE_END - CODE_START)

; save "STREAMER.ROM", #C000, #4000, AMSDOS
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 11:32, 23 June 23
BTW, after thought I am leaning towards virtual folders to group device types, such as AUDIO and put the virtual files under there for the streams.

Highly wanted suggestions for the main unidos core:

|s alias sys: for a configured system drive, e.g. we can assign m4: or ide: or whatever to be a system drive which then has an internal alias as sys: also which is preserved in NVM.  This allows us to know what drive is a nominated system drive.

|nvramsave and |nvramrestore for backing it up and/or transferring to other machines.  Separate external utility nvram which takes the saved nvram file and lists info such as which apps, which owners of segments etc...

I am thinking hard on this one... what is the most elegant way to implement piping and redirection.  

What is the current capacity of the nvram per node and did you go ahead with an allocation scheme or can you allocate a slot for me for this node.  Tentatively called streamer.  Perhaps that more stuff can be a separate node.  Tentatively memory manager.  

Soon people will be able to program in basic with some type of device independence for asset storage in extra memory, blitting to screen (and hopefully also v9990) without any of the 42k ram gone or worrying about banking.

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 15:58, 23 June 23
Quote from: zhulien on 10:04, 23 June 23hmm, GetName is called 8 times, I return C for 6 (now as I have 6 drives), and 2 NC.  Then it calls GetDesc not only for my 6 drives, but also for the 3 drives that are not even related to my Node.
You are right. When |DRIVE is issued, GetName is first called for drives 0-7.
Then CheckDrive will be called for each retrieved device name from GetName.
Then CheckStatus will be called for each retrieved device id from CheckDrive.
Then GetFreeSpace & GetDesc will be called for each device with a media inserted.

So, if your have additional calls, you may return C from CheckDrive when not expected. Unexpected behavior may also happen if your node (or another one) alters forbidden registers.

BTW, what do you mean by "drives that are not related to my node"?
All 0-7 drives are private to your node.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 16:01, 23 June 23
Quote from: zhulien on 02:26, 23 June 23If I do a cat on a write only DOS node, I get a Bad Command.
You need to implement minimal Examine/ExamineNext if you want to avoid this error.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 16:04, 23 June 23
Quote from: zhulien on 11:32, 23 June 23|s alias sys: for a configured system drive,
Yup, that's the plan!
SYS: alias is already in my todo list. It will come with extended assign support feature. ;)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 16:10, 23 June 23
Quote from: zhulien on 11:32, 23 June 23What is the current capacity of the nvram per node
nvram data is at least 2K. But it is totally private to UniDOS atm.
There are plans to add CTRL-J BIOS APIs so that external application could use it, but I still need to figure out what would be the good way to do so.

I first need to finalize extended assign support (both features are somewhat related internally).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 16:15, 23 June 23
Quote from: zhulien on 11:32, 23 June 23I am thinking hard on this one... what is the most elegant way to implement piping and redirection.  
According to me the simplest way would be a PIPE: drive working as a FIFO.
To start with, it could allocate system memory to store data, and later it could use the temporary data storage service planned in UniDOS.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 16:25, 23 June 23
Quote from: zhulien on 10:04, 23 June 23There are only 8 devices in a Node, of course we can have lots of nodes
Yep, current limitation is 8 nodes from 32 nodes, which makes 256 drives max (8-bit data).
It won't change until a major release because all the internal design as well as AMSDOS compatibility relies on a drive id which can fit in 8 bits.

As you suggested, having a sort of virtual path to dispatch streams might be the best idea to reduce the number of nodes. That said, I'm not sure that having a lot of nodes is an issue even if some of them are almost empty.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 16:27, 23 June 23
Quote from: zhulien on 11:32, 23 June 23Soon people will be able to program in basic with some type of device independence for asset storage in extra memory, blitting to screen (and hopefully also v9990) without any of the 42k ram gone or worrying about banking.
Sounds great!
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 17:50, 23 June 23
Quote from: OffseT on 16:04, 23 June 23
Quote from: zhulien on 11:32, 23 June 23|s alias sys: for a configured system drive,
Yup, that's the plan!
SYS: alias is already in my todo list. It will come with extended assign support feature. ;)
If you implement SYS:  Then the NVRAM is less needed as we could store config info in a SYS:UNIDOS folder for each node, perhaps we could standardise on node names for filenames.  If SYS: is also implemented then it will make my virtual memory more reliable than without - as e.g. SYS: could be nominated to IDE: regardless of which other drives are assigned to A and B.

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 17:52, 23 June 23
Here is the oddity I am getting with the descriptions:
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 17:53, 23 June 23
Perhaps Stream devices could be listed in their own section?  But I'm ok either way.  If I consolidate them to virtual folders / files, then they will become less.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 18:16, 23 June 23
Quote from: zhulien on 17:52, 23 June 23Here is the oddity I am getting with the descriptions:
Hmmm, looks like a display issue... This is typically what could happen if one of your DOSNode_* API is modifying a register which is not allowed (i.e. a register which is not lister as "Altered" in routine header). You may want to double check this.

If everything is ok on your side, please send me your node ROM file so that I could check what happens with the UniDOS |DRIVE display routine.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 18:20, 23 June 23
Quote from: zhulien on 17:53, 23 June 23Perhaps Stream devices could be listed in their own section?  But I'm ok either way.  If I consolidate them to virtual folders / files, then they will become less.
Yep, that's a good idea. Drives could be displayed in two separated lists. I add this to my todo list.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 19:13, 23 June 23
Do you have a simple example of how Examine and ExamineNext work?  The documentation for Examine doesn't mention copying anything to the buffer, but ExamineNext does - however if i look at DOSNode.a sourcecode, it appears that both might be copying to the buffer.

Examine - Check that a file or directory exists and return associated information

I am guessing that if HL = 0, then we return Z and C to force ExamineNext to get at least the first directory to examine.  What else calls ExamineNext to be called?

ld a, 1 ; test code
ld (#be80), a

ld a, h ; examine directory via ExamineNext
or l ;
jp z, DOSNode_Success ;

; do something else
xor a
ld a, %00010000
ld bc, 0
ld de, 0

jp DOSNode_Success


ExamineNext - Get the next entry from a directory being examined

If ExamineNext is called, how do i know where I am so far in a list of directory entries to return?  As I am returning 1 at a time.

ld a, (#be80)
or a
jp z, DOSNode_Fail

dec a
ld (#be80), a

ld de, DIRNAME
ex de, hl
ld bc, 11
ldir

xor a
ld a, %00010000
ld bc, 0
ld de, 0
jp DOSNode_Success

DIRNAME: db "TESTFILE   "

This example was for me just to try get it to list 1 hardcoded filename, but it gets stuck calling ExamineNext indefinitely.  The counter in #be80 was only to try force it to change behaviour after 1.  I must be not understanding the way the 2 functions work.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 12:42, 24 June 23
Quote from: zhulien on 19:13, 23 June 23Do you have a simple example of how Examine and ExamineNext work?
You can check the source code of Albireo node which is simple enough regarding catalog handling.

Anyway, the sequence is:
Call Examine with HL=0 to start examination of directory pointed by DE.
Call ExamineNext for each entry until it returns with C/NZ and A=dsk_err_file_not_found.

This is very similar to APIs from other operating systems to explore directory contents. It is up to the node to manage the current entry and the examination termination. Private data area to be used for Examine/ExamineNext management is located at (DOS_ROM_BASE_ADDRESS)+&3D0 and is &80 bytes long (which is usually far than enough).

All detailed are here:
https://unidos.cpcscene.net/doku.php?id=en:nœud_dos#routines_analyzing_files_and_directories

I hope it helps.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 18:29, 30 June 23
Thanks, seems to be me not returning the correct statuses in this case.  I still didn't resolve the description coming back for "other" nodes, but I can look into that again later when this Node becomes more functional.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 18:25, 03 August 23
Hi @OffseT is there any chance you can put a sys: or similar drive or is there one ready so that I can read a config file in my stream ROM.  Or... would you prefer I use the NVM somehow?  I could let someone make a config file and provide an rsx to load a form of its content into NVM.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 09:20, 05 August 23
Quote from: zhulien on 18:25, 03 August 23Hi @OffseT is there any chance you can put a sys: or similar drive or is there one ready so that I can read a config file in my stream ROM.  Or... would you prefer I use the NVM somehow?  I could let someone make a config file and provide an rsx to load a form of its content into NVM.
SYS: (or whatever name that will be used) is planned, not ready yet, because I have some preliminary work to do before (basically parts of UniDOS ROM are to be moved to UniTools ROM to save place for core features).

Btw, I should be able to release a new version before end of this year (including this feature plus some others).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: poulette73 on 12:21, 05 August 23
Hi OffSet,

Don't know if you see on CPCRulez but I found an issue with UniDOS few weeks ago.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 10:28, 06 August 23
Quote from: poulette73 on 12:21, 05 August 23Hi OffSet,

Don't know if you see on CPCRulez but I found an issue with UniDOS few weeks ago.
I actually missed this post, thank you for pointing me out.
I just answered on CPCRulez (http://cpcrulez.fr/forum/viewtopic.php?p=58991#p58991).
That's not a bug, that's a feature. 8)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 18:02, 06 August 23
As I understood, the Unidos is supposed to serve all mass storage devices.

Here my question: Is it planned to support the Dobbertin HD20 hard-disc?
(BTW: The HD20 is now emulated by the Symbiface 3 / RSF3).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Prodatron on 22:44, 06 August 23
Quote from: GUNHED on 18:02, 06 August 23Is it planned to support the Dobbertin HD20 hard-disc?
As nobody owns this device in real, there is no need for a support, and emulators also don't support it.
But why don't you write a UniDOS driver for it, if it's so important for you?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 00:35, 08 August 23
Quote from: Prodatron on 22:44, 06 August 23
Quote from: GUNHED on 18:02, 06 August 23Is it planned to support the Dobbertin HD20 hard-disc?
As nobody owns this device in real, there is no need for a support, and emulators also don't support it.
But why don't you write a UniDOS driver for it, if it's so important for you?
Well, I know at least five guys who own it. Four of them are visiting this place sometimes, some more often, some frequently. There is quite some interest.

It's imho very important, because of all the software for it. Perfect implementation for the native OS, for CP/M 2.2, for CP/M Plus and for the Z-System!!! (and other OS too, yes f.e. FutureOS). And in addition some bigger software projects are using it. (COSMOS f.e.). Have a look at the Wiki.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 20:26, 08 August 23
Even if I could own all existing hardware devices, I wouldn't have time to create a DOS node for any single existing one.
That's the reason why UniDOS is an opened DOS where anyone can create a new DOS node to support any new device.

I already created DOS nodes for most common devices, which can be used as a reference for new ones.
So, if you need support for a specific device, just do it! 8)

On my side, I also have to focus on UniDOS itself, many features are still to be added to the core ROM.
No new DOS nodes from my side are planned at the moment.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 09:03, 09 August 23
@GUNHED I am happy to share my DOSNODE code so far if you want it as a starting point - some bits are a challenge, but... it is more an understanding of how it works than it actually being difficult.  I think the most difficult bit might be how to match the code you have currently for the Dobbertin into the right DOSNODE APIs in the best way.  The DOSNODE APIs are pretty reasonable though.  There is also other DOSNODE full source available from the UniDOS official site.

I'm wondering... rather than use a very old legacy 20mb HDD (is it an MFM one?) wouldn't someone be better to make a new microcontroller circuit that might be compatible but... maps to a hardfile on an SDCARD or similar?  I think you suggested in the M4 card before - but that is up to @Duke.  I believe the Symbiface 3 does something like this right?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 13:22, 09 August 23
Well, I'm very busy with my own OS. However if somebody already made a DOS-NODE I can help with all stuff like: Read DIRectory, read/write file, erase/rename file and so on. Also I can help with technical things.

Speaking of technical things: It's very easy, basically you only need to read/write a sector. And all you need to do is to tell the controller which sector, cylinder, head you want to use. That's it.  :)

The idea of UniDOS is great, but it won't work if it's not supporting all mass storage devices imho. Because then we end up to need different DOS again. So I hope that one day some cool coder will also do a DOS-Node for the HD20 hard-disc. BTW: It was and still is the most often sold mass storage device for CPC (regarding storage space bigger than a floppy disc).
(One of the reasons for me to make FutureOS was to have everything in one OS - to eliminate the need to switch between DOS/OS all the time).
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Prodatron on 21:17, 09 August 23
Quote from: GUNHED on 13:22, 09 August 23The idea of UniDOS is great, but it won't work if it's not supporting all mass storage devices
UniDOS supports most of the actual mass storage devices.
It probably works much better than something that almost only supports storage devices from the 80s.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: eto on 11:12, 14 August 23
Quote from: GUNHED on 13:22, 09 August 23So I hope that one day some cool coder will also do a DOS-Node for the HD20 hard-disc.
It probably has to be someone who owns a HD20 and is interested to use it with UniDOS. 

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 10:12, 15 August 23
what is the current price of a HD20 secondhand if someone has one?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: eto on 11:47, 15 August 23
Quote from: zhulien on 10:12, 15 August 23what is the current price of a HD20 secondhand if someone has one?
I have some saved searches on Ebay with daily notifications since early 2020. I can't remember that a single one was offered. 

But that is no surprise. It's a wonder if such an old hard drive is still working and honestly I would not put any relevant data on it.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 14:19, 17 August 23
Quote from: zhulien on 10:12, 15 August 23what is the current price of a HD20 secondhand if someone has one?
Well, users owning such a device will probably not sell it, because it's a real gem.
However, now there is support of the HD20 with Symbiface III. So if you own an SF3 then you can already use the HD20. More information in the SF3 creators group at slackbot.

Support of the HD20 in UniDOS would push the idea of supporting any kind of mass storage.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Prodatron on 21:43, 17 August 23
Can you present this SF3 support on the XzX and show the important (CP/M?) software, which is supporting the HD20? Would be interesting.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 21:53, 17 August 23
Quote from: Prodatron on 21:43, 17 August 23Can you present this SF3 support on the XzX and show the important (CP/M?) software, which is supporting the HD20? Would be interesting.
Everybody can go to the slack group of the SF3 / RSF3 and there join the HD20 emu group.
There you can get an firmware update (see thread) and the HD20 image.

After installing the image on USB:/HD20/ and installing X-DDOS as (active DOS) ROM you can use commands like !CPM,4 (5, 6, 7) to start different CP/M versions. The software is all right there, as long as you know you CP/M basics like user numbers. Also the Z system is on this image - the Unix for the CP/M Plus (CPC in this case).

The HD20 emulation team can be joined here:
https://app.slack.com/client/TCVGGRXPH/C03M0GS1BJS
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Prodatron on 21:58, 17 August 23
Looking forward to your presentation! :)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: eto on 12:01, 18 August 23
I would also love to see what you can do with it and what all the software is, that supports the HD20. Never saw it, never heard of it and I am lacking the imagination, what all that could be. 

A presentation with real examples, maybe a short video, would be awesome.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 12:54, 18 August 23
Quote from: Prodatron on 21:58, 17 August 23Looking forward to your presentation! :)
Thanks for being supportive - the HD20 emulation deserves it!  :)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 12:56, 18 August 23
Quote from: eto on 12:01, 18 August 23I would also love to see what you can do with it and what all the software is, that supports the HD20. Never saw it, never heard of it and I am lacking the imagination, what all that could be.

A presentation with real examples, maybe a short video, would be awesome.
Yes, a video would be nice. We got quite some experts regarding CPC videos in this forum. Personally I don't own such professional equipment though.

And...
https://www.cpcwiki.eu/index.php/Dobbertin_Harddisc#Software_using_the_Dobbertin_Harddrive
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Prodatron on 16:23, 18 August 23

Quote from: eto on 12:01, 18 August 23Never saw it, never heard of it and I am lacking the imagination, what all that could be.
Here the same.


Quote from: eto on 12:01, 18 August 23A presentation with real examples, maybe a short video, would be awesome.
I will do a video next weekend when TFM is doing his HD20 presentation on the XzentriX.


Quote from: GUNHED on 12:56, 18 August 23Personally I don't own such professional equipment though.
It's called "smartphone".
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: SkulleateR on 21:32, 09 December 23
What is the correct way to access real Floppy Drives with UniDOS ?

In the readme it says, real drives can be accessed with DFA: and DFB: but I cannot access them ...

Right now I'm using it with an Albireo SD, so everything is mapped to SD:

If I try a LOAD"DFA:TEST.BAS" it says Bad command
IDRIVE,"A","DFA:" also results in a Bad command

If I call Idrive I can see both physical drives are set to SD:

I can of course set the drives to any directory on the sd card, that's no problem but I need to access the real disk drives ... any hints ?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: m_dr_m on 08:01, 10 December 23
You are correct, DFA: and DFB: are the proper device names.
Do you see them under "Available Devices" when doing |DRIVE ?

Is AMSDOS still in ROM 7 and UNIDOS under ROM 7? (1 to 6)
Or alternatively in ROM 15 if UNIDOS occupies ROM 7?
As per Documentation (https://unidos.cpcscene.net/doku.php?id=en:install).

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 14:04, 10 December 23
Quote from: SkulleateR on 21:32, 09 December 23What is the correct way to access real Floppy Drives with UniDOS ?
DFA:/DFB: are actually the proper DOS device names.
"Bad command" happens when you access a non-existing device.
As stated by Madram, you need to have AMSDOS or ParaDOS installed, because UniDOS rely on them to provide floppy support.

If AMSDOS or ParaDOS is available, UniDOS should display "integrated" during boot, otherwise, it will display "standalone".

You can also check the devices detected by each node using |NODE RSX. Without parameter it will display all the detected DOS nodes; and if you provide one, it will display the list of the detected devices by the provided node number.

For instance:
|NODE,<number of UniDOS ROM> will list the devices UniDOS detected internally. If AMSDOS is installed, you will see DFA:/DFB:. If not, they won't appear.

|DRIVE itself works a bit differently. It will display the devices which are available from all the detected DOS nodes at the time it is issued. In that case, DFA:/DFB: will only appear if AMSDOS is installed and a floppy disc is inserted.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: SkulleateR on 14:32, 10 December 23
Seems I got a hickup in the Rom installation ... did it all from scratch and now it is working :)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 18:31, 13 December 23
A bit lost :D

If anybody has some time to look at the following code, much appreciated - 2 issues I don't yet get...

1. the wrong description against some drives when performing a |drive command
2. the way examine and examine next work - currently wondering why I get 100s of TESTFILE rather than 1, I was using location #BE80 as a flag (not intended to stay that way).

The node is supposed to have 4 drives, if you for example change A drive to be VIDEO (load "VIDEO:") then |DRIVE should list the correct names etc... if you then save"ANYTEXT" it will literally put ANYTEXT on the screen - but also some junk for some reason.

org #c000

 ;write direct #C000, #0a

CODE_START:

ROMType db 2; 1 (secondary ROM) or 2 (expansion ROM)

ROMMark db 1; It is customary that the version of a ROM
ROMVer db 4; is displayed in the form M VR
ROMRev db 1; (i.e. 1.00 here)

ROMRSX dw RSXTable

 jp InitROM
 jp DOSNode_Init ; implemented, 1, called once, A = 1
 jp DOSNode_CheckDrive ; implemented, 3, called once, HL = Streamer, Return 0
 jp DOSNode_GetStatus ; implemented, 4, called once, A = 0
 jp DOSNode_GetName ; implemented, 2, called 8 times, A = 0 to 7
 jp DOSNode_GetDesc ; implemented, 6, called once, A = 0
 jp DOSNode_GetFreeSpace ; implemented, 5, called once, A = 0
 jp DOSNode_InOpenStream
 jp DOSNode_InReadStream
 jp DOSNode_InCloseStream
 jp DOSNode_InSeekStream
 jp DOSNode_OutOpenStream ; implemented
 jp DOSNode_OutWriteStream ; implemented
 jp DOSNode_OutCloseStream ; implemented
 jp DOSNode_OutSeekStream
 jp DOSNode_Examine
 jp DOSNode_ExamineNext
 jp DOSNode_Rename
 jp DOSNode_Delete
 jp DOSNode_CreateDir
 jp DOSNode_SetProtection
 jp DOSNode_Format
 jp DOSNode_SetFileDate
 jp DOSNode_Void
 jp DOSNode_Void
 jp DOSNode_Void
 jp DOSNode_ReadRTC
 jp DOSNode_WriteRTC
 jp DOSNode_OpenNVRAM
 jp DOSNode_CloseNVRAM
 jp DOSNode_ReadNVRAM
 jp DOSNode_WriteNVRAM
 jp DOSNode_SeekNVRAM
 ; You can add your personal RSX here (if ROM type 1)

RSXTable
 str "STREAMER"
 str "DOS Node"

 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80
 db #80

 ; You can add your personal RSX here (if ROM type 1)
 db 0; End of the RSX table

        ; Actual ROM code starts here
InitROM: cp a
 ret
 
BYTES_FREE_HW equ #00ff ; high word
BYTES_FREE_LW equ #ffff ; low word
DAC_DELAY equ 4 ; slow dac playing a bit
PORT_AMDRUM equ #ff
PORT_MMACHINE equ #f8f0

MC_PRINT_CHAR equ #bd2b
TXT_OUT_CHAR equ #bb5a

Drive_AUD equ #0
Drive_PRN equ #1
Drive_TLK equ #2
Drive_VID equ #3

DriveNames:
DriveNameAUD: db "AUDI", "O" + #80, 0, Drive_AUD
DriveNamePRN: db "PRIN", "T" + #80, 0, Drive_PRN
DriveNameTLK: db "TAL", "K" + #80, 0, Drive_TLK
DriveNameVID: db "VIDE", "O" + #80, 0, Drive_VID
 db 0

DriveDescAUD: db "Audio Device", "s" + #80, 0
DriveDescPRN: db "Printer Device", "s" + #80, 0
DriveDescTLK: db "Talking Device", "s" + #80, 0
DriveDescVID: db "Video Device", "s" + #80, 0

AUD_AMDRM: db "AMDRUM    ", 0
AUD_MMACH: db "MMACHINE  ", 0
PRN_7BIT: db "7BIT      ", 0
TALK_SSA1: db "SSA1      ", 0
TALK_DKTRONIC: db "DKTRON    ", 0
VID_ASCII: db "ASCII      ", 0

;
; Initialize the noeud DOS
;
; Input  - A = initialization status (see flags Init_*)
;              Bit0 = 1 if the CPC is doing a cold boot
;              Other bits are unused
; Output  - If Carry = 1 then the node was intialized
;          If Carry = 0 then the node could not be initialized
; Altered - AF

DOSNode_Init: xor a
 jp DOSNode_Success

;
; Check if a drive name is handled by the DOS node
;
; Input  - HL = pointer to the drive name
;                (bit 7 could be set on some character and mush be ignored)
;          C = length of the drive name
; Output - If Carry = 1 a drive was found in the node
;                A = physical drive number
;          If Carry = 0 the drive was not found in the node
; Altered - AF

DOSNode_CheckDrive:
 push de
 push hl
 ld de, DriveNames
 ex de, hl
 call ListGetIDByName
 pop hl
 pop de
 jp nz, DOSNode_Fail
 jp DOSNode_Success

;
; Return a drive status
;
; Input  - A = drive number
; Output  - If Carry = 1 a status was returned
;                A = status of the drive (see flags flags Media_*)
;                    Bit0 = 1 if a media is inserted in the drive
;                    Bit1 = 1 if the media support 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)
;                        $$$ and BAK filesis then disabled
;                    Bit5 = 1 if the media can be reached by the new UniDOS API
;                    Other bits are unused
;          If Carry = 0 then the drive is unknown and no status was returned
; Alteted - AF

DOSNode_GetStatus:
 cp Drive_AUD
 jr z, DOSNode_GetStatusEnd

 cp Drive_PRN
 jr z, DOSNode_GetStatusEnd

 cp Drive_TLK
 jr z, DOSNode_GetStatusEnd

 cp Drive_VID
 jr z, DOSNode_GetStatusEnd

 jp DOSNode_Fail

DOSNode_GetStatusEnd:
 ld a, %000110001
 jp DOSNode_Success

;
; Return the name corresponding to a physical drive
;
; Input  - A = drive number
;          DE = address of a buffer of 8 bytes when to store the name
; Output  - If Carry = 1 the name was found
;                DE points to the first character after the end of the copied string
;                (the string is stored with the bit 7 of its last character set)
;          If Carry = 0 not description was found and the buffer is left unchanged.
; Altered - AF,DE

DOSNode_GetName:
 push hl
 
 cp Drive_AUD
 ld hl, DriveNameAUD
 jr z, DOSNode_GetNameCopy

 cp Drive_PRN
 ld hl, DriveNamePRN
 jr z, DOSNode_GetNameCopy

 cp Drive_TLK
 ld hl, DriveNameTLK
 jr z, DOSNode_GetNameCopy

 cp Drive_VID
 ld hl, DriveNameVID
 jr z, DOSNode_GetNameCopy

 pop hl
 jp DOSNode_Fail

DOSNode_GetNameCopy:
 call StrCopy
 pop hl
 jp DOSNode_Success
 
;
; Return the description corresponding to a physical drive
;
; Input  - A = drive number
;          DE = addess of the 32 bytes buffer where to store the description
; Ouput  - If Carry = 1 a description was found
;                DE points to the first character after the end of the copied string
;                (the string is stored with the bit 7 of its last character set)
;          If Carry = 0 not description was found and the buffer is left unchanged.
; Altered - AF,DE

DOSNode_GetDesc:
 push hl
 
 cp Drive_AUD
 ld hl, DriveDescAUD
 jr z, DOSNode_GetDescCopy

 cp Drive_PRN
 ld hl, DriveDescPRN
 jr z, DOSNode_GetDescCopy

 cp Drive_TLK
 ld hl, DriveDescTLK
 jr z, DOSNode_GetDescCopy

 cp Drive_VID
 ld hl, DriveDescVID
 jr z, DOSNode_GetDescCopy

 pop hl
 jp DOSNode_Fail

DOSNode_GetDescCopy:
 call StrCopy
 pop hl
 jp DOSNode_Success

;
; Return the free space on a physical drive
;
; Input  - A = drive number
; Output  - If Carry = 1 the routine is supported for this drive
;                If Z then the free space could be obtained
;                    BCDE = free space in kilo-bytes
;                If NZ then an error occured
;                    A = error code
;          If Carry = 0 then the routines is invalid for this drive
; Altered - AF,BC,DE

DOSNode_GetFreeSpace:
 cp Drive_AUD
 jr z, DOSNode_GetFreeSpaceEnd

 cp Drive_PRN
 jr z, DOSNode_GetFreeSpaceEnd

 cp Drive_TLK
 jr z, DOSNode_GetFreeSpaceEnd

 cp Drive_VID
 jr z, DOSNode_GetFreeSpaceEnd

 jp DOSNode_Fail

DOSNode_GetFreeSpaceEnd:
 ld bc, BYTES_FREE_HW
 ld de, BYTES_FREE_LW
 xor a
 jp DOSNode_Success

;
; Open the input stream
;
; Input  - A = drive number
;          HL = pointer to the normalized name
;              note, if the drive is of type stream then this name can
;              contain 11x&ff in case where no file name was provided
;              by the user (when he uses the anonymous reference ".");
;              the routine should then just open the just encountered
;              file on the stream and can optionally update the name
;              if it could be obtained from the stream itself
;          DE = pointer the normalized path
;          The pointed memory is always located in the current ROM/RAM space area
; Ouput  - If Carry = 1 the routine is supported for the provided drive
;                If Z then a file was opened
;                If NZ then no file could be opened
;                    A = error code
;              In any case, the routine might truncate the provided normalized path to match the nearest parent
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_InOpenStream:
 jp DOSNode_Fail

;
; Read from the input stream
;
; Input  - A = drive number
;          HL = address where to stored the read data
;          DE = number of bytes to read
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then data could be read
;                    DE = number of bytes read
;                If NZ then a error occured
;                    A = error code
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF,DE

DOSNode_InReadStream:
 jp DOSNode_Fail

;
; Close the input stream
;
; Input  - A = drive number
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the stream was properly closed
;                If NZ then the stream was closed with an error
;                    A = error code
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_InCloseStream:
 jp DOSNode_Fail

;
; Change the position into the input stream
;
; Input  - A = drive number
;          DEHL = new position in the input stream
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the new position could be reached
;                If NZ then an error occured
;                    A = error code
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_InSeekStream:
 jp DOSNode_Fail

;
; Open the output stream
;
; Input  - A = drive number
;          HL = pointer to the normalized name
;          DE = pointer to the normalized path
;          The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then a file was created
;                If NZ then no file was created
;                    A = error code
;              In any case, the routine might truncate the provided normalized path to match the nearest parent
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_OutOpenStream:
 cp Drive_AUD
 jp z, DOSNode_Success

 cp Drive_PRN
 jp z, DOSNode_Success

 cp Drive_TLK
 jp z, DOSNode_Success

 cp Drive_VID
 jp z, DOSNode_Success

 jp DOSNode_Fail

;
; Write into the ouput stream
;
; Input  - A = drive number
;          HL = address where are located the data to write
;          DE = number of bytes to write
; Sortie - If Carry = 1 the routine is supported for the provided drive
;                If Z then data could be written
;                    DE = nomber of written bytes
;                If NZ then an error occured
;                    A = error code
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF,DE

DOSNode_OutWriteStream:
 cp Drive_AUD
 jr z, DOSNode_OutWriteStream_AUD

 cp Drive_PRN
 jr z, DOSNode_OutWriteStream_PRN

 cp Drive_TLK
 jr z, DOSNode_OutWriteStream_TLK

 cp Drive_VID
 jr z, DOSNode_OutWriteStream_VID

 jp DOSNode_Fail

; ----------------------------------------

DOSNode_OutWriteStream_AUD:

 push hl
 push bc
 di

DOSNode_OutWriteStream_AUDLoop:

 ld b, DAC_DELAY

DOSNode_OutWriteStream_AUDLoop2:

 push bc
 
 ld c, (hl)
 ld b, PORT_AMDRUM
 out (c), c

 pop bc
 djnz DOSNode_OutWriteStream_AUDLoop2
 
 inc hl
 dec de
 
 ld a,d
 or e
 jr nz, DOSNode_OutWriteStream_AUDLoop

DOSNode_OutWriteStream_AUDEnd:
 ei
 pop bc
 pop hl
 jp DOSNode_Success

; ----------------------------------------

DOSNode_OutWriteStream_PRN:

 push hl

DOSNode_OutWriteStream_PRNLoop:
 ld a, (hl)
 ;call ValidateChar
 ;jr nc, DOSNode_OutWriteStream_PRNSkip

 call MC_PRINT_CHAR
 
;DOSNode_OutWriteStream_PRNSkip:
 inc hl
 dec de
 
 ld a,d
 or e
 jr nz, DOSNode_OutWriteStream_PRNLoop

DOSNode_OutWriteStream_PRNEnd:
 pop hl
 jp DOSNode_Success
 
; ----------------------------------------

DOSNode_OutWriteStream_TLK:
 jp DOSNode_Success

; ----------------------------------------

DOSNode_OutWriteStream_VID:

 push hl

DOSNode_OutWriteStream_VIDLoop:
 ld a, (hl)
 call ValidateChar
 jr nc, DOSNode_OutWriteStream_VIDSkip

 call TXT_OUT_CHAR
 
DOSNode_OutWriteStream_VIDSkip:
 inc hl
 dec de
 
 ld a,d
 or e
 jr nz, DOSNode_OutWriteStream_VIDLoop

DOSNode_OutWriteStream_VIDEnd:
 pop hl
 jp DOSNode_Success

;
; Close the output stream
;
; Input  - A = drive number
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the stream was properly closed
;                If NZ then the stream was closed with an error
;                    A = error code
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_OutCloseStream:
 cp Drive_AUD
 jp z, DOSNode_Success

 cp Drive_PRN
 jp z, DOSNode_Success

 cp Drive_TLK
 jp z, DOSNode_Success

 cp Drive_VID
 jp z, DOSNode_Success

 jp DOSNode_Fail

;
; Change the position into the output stream
;
; Input  - A = drive number
;          DEHL = new position in the ouput stream
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the new position could be reached
;                If NZ then an error occured
;                    A = error code
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_OutSeekStream:
 jp DOSNode_Fail

;
; Check that a file or directory exists and return associated information
;
; Input  - A = drive number
;          HL = pointer to the normalized name
;              If HL = 0 then it is the contents of the directory which has to be analyzed
;              and ExamineNext will be called next to retrieve each entry
;          DE = pointer to the normalized path
;          IX = buffer where to store last modification time and date
;          The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;
;                If HL was not 0 in input
;                    If Z then the file or directory exists
;                        A = protection bits of the file
;                            Bit 0 - Read-only
;                            Bit 1 - Hidden
;                            Bit 2 - System
;                            Bit 4 = Directory
;                            Bit 5 = Archived
;                        BCDE = Length of the file
;                        IX = buffer where last modification time and date of the entry were stored
;                            One 16-bit word with year (1978..9999)
;                            One byte with number of month (1..12)
;                            One byte with number of day in the month (1..28,29,30 or 31)
;                            One byte with hours (0..23)
;                            One byte with minutes (0..59)
;                            One byte with seconds (0..59)
;                    If NZ then the file or directory was not found
;                        A = error code
;
;                If HL was 0 in input
;                    If Z then the directory is ready to be examined through ExamineNext
;                    If NZ then an error occurred
;                        A = error code
;
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_Examine:
 cp Drive_AUD
 jr z, DOSNode_Examine_AUD

 cp Drive_PRN
 jr z, DOSNode_Examine_PRN

 cp Drive_TLK
 jr z, DOSNode_Examine_TLK

 cp Drive_VID
 jr z, DOSNode_Examine_VID

 jp DOSNode_Fail

DOSNode_Examine_AUD:
DOSNode_Examine_PRN:
DOSNode_Examine_TLK:
DOSNode_Examine_VID:
 ld a, 1 ; test code
 ld (#be80), a

 ld a, h ; examine directory via ExamineNext
 or l ;
 jp z, DOSNode_Success ;
 
 ; do something else
 xor a
 ld a, %00010000
 ld bc, 0
 ld de, 0

 jp DOSNode_Success

;
; Get the next entry from a directory being examined
;
; Input  - A = drive number
;          HL = pointer to the memory where to store the normalize name
;          IX = buffer where to store last modification time and date
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then an entry was found
;                    HL = pointer to the memory updated with the found normalized name
;                        A = protection bits of the file
;                            Bit 0 - Read-only
;                            Bit 1 - Hidden
;                            Bit 2 - System
;                            Bit 4 = Directory
;                            Bit 5 = Archived
;                        BCDE = Length of the file
;                        IX = buffer where last modification time and date of the entry were stored
;                            One 16-bit word with year (1978..9999)
;                            One byte with number of month (1..12)
;                            One byte with number of day in the month (1..28,29,30 or 31)
;                            One byte with hours (0..23)
;                            One byte with minutes (0..59)
;                            One byte with seconds (0..59)
;                If NZ then an error occurred
;                    A = error code (dsk_err_file_not_found indicates that all entries were examined)
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_ExamineNext:
 cp Drive_AUD
 jr z, DOSNode_ExamineNext_AUD

 cp Drive_PRN
 jr z, DOSNode_ExamineNext_PRN

 cp Drive_TLK
 jr z, DOSNode_ExamineNext_TLK

 cp Drive_VID
 jr z, DOSNode_ExamineNext_VID

 jp DOSNode_Fail

DOSNode_ExamineNext_AUD:
DOSNode_ExamineNext_PRN:
DOSNode_ExamineNext_TLK:
DOSNode_ExamineNext_VID:

 ld a, (#be80)
 or a
 jp z, DOSNode_Fail

 dec a
 ld (#be80), a
 
 ld de, DIRNAME
 ex de, hl
 ld bc, 11
 ldir
 
 xor a
 ld a, %00010000
 ld bc, 0
 ld de, 0
 jp DOSNode_Success

DIRNAME: db "TESTFILE  "

;
; Rename a file or a directory
;
; Input  - A = drive number
;          HL = pointer to the normalized name
;          DE = pointer to the normalized path
;          IX = pointer to the new normalized name
;          BC = pointer to the new normalized path
;          The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the file or directory was renamed
;                If NZ then the file or directory could not be renamed
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF
 
DOSNode_Rename: jp DOSNode_Fail

;
; Delete a file or a directory
;
; Input  - A = drive number
;          HL = pointer to the normalized name
;          DE = pointer to the normalized path
;          The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the file or directory was deleted
;                If NZ then the file or directory could not be deleted
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_Delete: jp DOSNode_Fail

;
; Create a directory
;
; Input  - A = drive number
;          HL = pointer to the normalized name
;          DE = pointer to the normalized path
;          The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the directory was created
;                If NZ then the directory could not be created
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_CreateDir:
 jp DOSNode_Fail

;
; Change the protection bits of a file
;
; Input  - A = drive number
;          HL = pointer to the normalized name
;          DE = pointer to the normalized path
;          B = Protections to modify
;          C = New protections
;                Bit 0 - Read-only
;                Bit 1 - Hidden
;                Bit 5 = Archived
;          Other bits are ignored
;          The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the protections were modified
;                If NZ then the protections could not be modified
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_SetProtection:
 jp DOSNode_Fail

;
; Change last modification time and date of a file or a directory
;
; Input  - A = drive number
;          HL = pointer to the normalized name
;          DE = pointer to the normalized path
;          IX = buffer where last modification time and date to use for the entry are stored
;              One 16-bit word with year (1978..9999)
;              One byte with number of month (1..12)
;              One byte with number of day in the month (1..28,29,30 or 31)
;              One byte with hours (0..23)
;              One byte with minutes (0..59)
;              One byte with seconds (0..59)
;          The pointed memory is always located in the current ROM/RAM space area
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the time and date were modified
;                If NZ then the time and date could not be modified
;                    A = error code
;                In any case, the routine might truncate the provided normalized path to match the nearest parent
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_SetFileDate:
 jp DOSNode_Fail
 
;
; Format a drive
;
; Input  - A = drive number
; Output  - If Carry = 1 the routine is supported for the provided drive
;                If Z then the drive was formatted
;                If NZ then format failed
;                    A = error code
;          If Carry = 0 then the routine is invalid for the provided drive
; Altered - AF

DOSNode_Format: jp DOSNode_Fail
 
;
; Read the contents of the real time clock
;
; Input  - IX = buffer where to store current time and date (7 octets)
; Output  - If Carry = 1 the the DOS node handles a relax time clock
;                IX = buffer where current time and date were stored
;                    One 16-bit word with year (1978..9999)
;                    One byte with number of the month (1..12)
;                    One byte with the number of the day in the month (1..28,29,30 or 31)
;                    One byte with hours (0..23)
;                    One byte with minutes (0..59)
;                    One byte with seconds (0..59)
;                A = number of the day in the week (1..7, from Monday to Sunday)
;          If Carry = 0 the the DOS node do not handle a real time clock
; Altered - AF

DOSNode_ReadRTC:
 jp DOSNode_Fail

;
; Write into the real time clock
;
; Input  - IX = buffer containing time and date to write into real time clock (7 bytes)
;              One 16-bit word with year (1978..9999)
;              One byte with number of the month (1..12)
;              One byte with the number of the day in the month (1..28,29,30 or 31)
;              One byte with hours (0..23)
;              One byte with minutes (0..59)
;              One byte with seconds (0..59)
; Output  - If Carry = 1 then the DOS node handles a real time clock
;              If Z then the contents of the real time clock was updated
;              If NZ then an error occurred
;                  A = error code
;          If Carry = 1 then the DOS node do not handle a real time clock
; Altered - AF

DOSNode_WriteRTC:
 jp DOSNode_Fail

;
; Open the non volatile memory
;
; Input  - C = opening mode
;                If 0 then the non volatile memory shall be opened with its current contents
;                If 1 then the non volatile memory shall be opened with its contents reset
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then the non volatile memory has been opened and is ready for usage
;                If NZ then a error occured
;                    A = error code
;          If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF

DOSNode_OpenNVRAM:
 jp DOSNode_Fail

;
; Close and update the non volatile memory memory contents
;
; Input  - None
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then the non volatile memory was properly updated
;                If NZ then an error occured
;          If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF

DOSNode_CloseNVRAM:
 jp DOSNode_Fail

;
; Read data from the non volatile memory
;
; Input  - HL = address where to write read data
;          DE = number of bytes to read
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then data were read
;                    DE = number of bytes read
;                If NZ then a error occured
;                    A = error code
;          If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF,DE

DOSNode_ReadNVRAM:
 jp DOSNode_Fail

;
; Write data to the non volatile memory
;
; Input  - HL = address where a located data to write
;          DE = number of bytes to write
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then data were written
;                    DE = number of bytes written
;                If NZ then a error occured
;                    A = error code
;          If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF,DE

DOSNode_WriteNVRAM:
 jp DOSNode_Fail

;
; Change the position in the non volatile memory
;
; Input  - DEHL = new position
; Output  - If Carry = 1 then the DOS node provides non volatile memory
;                If Z then the new position was reached
;                If NZ then a error occured
;                    A = error code
;          If Carry = 0 then the DOS node do not provide non volatile memory
; Altered - AF,DE

DOSNode_SeekNVRAM:
 jp DOSNode_Fail

DOSNode_Void: ret

DOSNode_Fail: ccf
 ret

DOSNode_Success:
 scf
 ret

 ; ------------------------- ListGetIDByName
 ; -- parameters:
 ; -- HL = address of list to find a string within
 ; -- DE = string to find
 ; --
 ; -- return:
 ; -- Z if found, NZ if not
 ; -- A = entry number of found item
 ; -- all other registers unknown

ListGetIDByName:
 ld a, (hl)
 or a
 jr z, ListGetIDByNameNotFound

 push de
 push hl
 call StrCompare
 pop hl
 call StrSkip
 pop de

 jr z, ListGetIDByNameFound
 
 inc hl
 inc hl
 jr ListGetIDByName
 
ListGetIDByNameFound:
 inc hl
 ld a, (hl)
 ret
 
ListGetIDByNameNotFound:
 xor a
 ret
 
 ; ------------------------- StrCompare
 ; -- parameters:
 ; -- HL = zero terminated string source of truth
 ; -- DE = string to compare
 ; --
 ; -- return:
 ; -- Z if equal, NZ if not
 ; -- all other registers unknown

StrCompare:
StrCompareLoop:
 ld a, (hl)
 or a
 ret z ; found it, return

 call ToUpper
 and #7f
 
 push af
 ld a, (de)
 call ToUpper
 and #7f
 ld b, a
 pop af
 
 cp b
 ret nz ; didnt find it, return
 inc hl
 inc de
 jr StrCompareLoop

 ; ------------------------- ToUpper
 ; -- parameters:
 ; -- A = character to make into uppercase
 ; --
 ; -- return:
 ; -- A = uppercase character
 ; -- all other registers preserved except flags

ToUpper: cp 'a'
 ret c
 cp 'z' + 1
 ret nc
 add a, 'A' - 'a'
 ret
 
 ; ------------------------- StrCopy
 ; -- parameters:
 ; -- HL = source string address
 ; -- DE = destination string address
 ; --
 ; -- return:
 ; -- HL = the address of the source string terminator
 ; -- DE = the address of the destination string terminator
 ; -- all other registers unknown

StrCopy:
 ld a,(hl)
 ld (de), a
 or a
 ret z ; end of string return
 inc hl
 inc de
 jr StrCopy
 
StrSkip: push af

StrSkipLoop:
 ld a,(hl)
 or a
 jr z, StrSkipEnd
 inc hl
 jr StrSkipLoop
 
StrSkipEnd: pop af
 ret

 ; ------------------------- ValidateChar
 ; -- parameters:
 ; -- A = character to validate
 ; --
 ; -- return:
 ; -- C if valid, NC if not
 ; -- all other registers preserved

ValidateChar:
 cp ' '
 jr c, DOSNode_Fail

 cp 'z'
 jr nc, DOSNode_Fail

 jp DOSNode_Success

CODE_END: ; ds #4000 - (CODE_END - CODE_START)

; save "STREAMER.ROM", #C000, #4000, AMSDOS

Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 00:44, 16 December 23
The first thing you should check is that you only alter the registers indicated in the routine headers. UniDOS expects those. If you alter a register which is supposed to be preserved by the routine, some unpredictable things may happen.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 13:33, 28 January 24
Just another feature request that st least the api could perhaps be added as stubs.

That is. New capability of random access

And new driver apis for seeking and such.  Random access should be on amsdos and never really was.  UniDOS is the only dos that sees the bigger picture to allow all devices to one day support it.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Prodatron on 19:39, 28 January 24
IIRC UniDOS already supports random file access.
Pulko Mandy is using this for streaming from a file in his VGM player for the Willy/OPL3 device.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 11:29, 30 January 24
Quote from: Prodatron on 19:39, 28 January 24IIRC UniDOS already supports random file access.
Pulko Mandy is using this for streaming from a file in his VGM player for the Willy/OPL3 device.
cool, i'm still stuck with my DOS node - same issue, not a clear documenation on how one API relates to another... one day i will get there.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 17:55, 30 January 24
Quote from: zhulien on 13:33, 28 January 24That is. New capability of random access
This is actually already supported.

See additional APIs for read/write here:
https://unidos.cpcscene.net/doku.php?id=en:devel#cmd_cas_in_read_5

And as stated by @Prodatron it is used by the VGM player to stream data. It is also used by UniLoad to go thru the 1MB game database.

VGM player here:
https://framagit.org/shinra/vgmplay
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 10:11, 14 February 24
I finally resolved my issue - the documentation is ambiguous and I obviously interpretted it wrongly.

;
; Check if a drive name is handled by the DOS node
;
; Input   - HL = pointer to the drive name
;                (bit 7 could be set on some character and mush be ignored)
;           C = length of the drive name
; Output - If Carry = 1 a drive was found in the node
;                A = physical drive number
;           If Carry = 0 the drive was not found in the node
; A = MUST BE PRESERVED <--- I added this line
; Altered - AF

Because the AF being altered at the bottom, I made the assumption that it doesn't matter what A is if Carry = 0, but it makes a huge difference.

So, now I'm 90% through my first DOS Node and it works so far.

A couple of questions.

1. ExamineNext when doing a CAT, HL points to ROOT (for example) but when doing a |DIR, HL points to [ROOT (for example). Is it intentional that they behave slightly differently and am i supposed to check for both ROOT and [ROOT] for example?

2. when I open a stream, I am given the folder name that I am opening the stream into - but at the time of writing the stream, I don't have that anymore - temporarily I stored a pointer at #be80, but that is not a good solution for this.  How do I reserve some bytes of memory for every output file that can be written to concurrently?  What is the best way to do this? 
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 17:11, 14 February 24
Finally made a git repo for it.

The Readme needs tidying up but my internet has gone today so will fix it when that comes back.

https://github.com/PrimalNinja/Streamer
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 18:26, 14 February 24
Quote from: zhulien on 10:11, 14 February 24I finally resolved my issue - the documentation is ambiguous and I obviously interpretted it wrongly.
That's very good news! 👍
Your node sounds promising and will be really useful!

Sorry for the misleading documentation. 😰
 I fixed it on the website.

Quote from: zhulien on 10:11, 14 February 241. ExamineNext when doing a CAT, HL points to ROOT (for example) but when doing a |DIR, HL points to [ROOT (for example). Is it intentional that they behave slightly differently and am i supposed to check for both ROOT and [ROOT] for example?
When a CAT or |DIR is issued on the root directory, HL will always be 0 and DE will point to an empty path. Additionally, files names and paths are always normalized. You will never have to deal with paths like ROOT or [ROOT] which are pure displayable forms.

Quote from: zhulien on 10:11, 14 February 242. when I open a stream, I am given the folder name that I am opening the stream into - but at the time of writing the stream, I don't have that anymore - temporarily I stored a pointer at #be80, but that is not a good solution for this.  How do I reserve some bytes of memory for every output file that can be written to concurrently?  What is the best way to do this? 
AMSDOS, and consequently UniDOS, can only handle two opened files at the same time. One as input, the other as output. Then, you can used the memory area reserved for you by UniDOS for this purpose. From UniDOS documentation:

QuoteRoutines handling the input file
Because of the operating system, only one file at once can be opened as output, which makes the implementation on these routines quite simple.
The DOS node can use 80 bytes at offset +&3305) (https://unidos.cpcscene.net/doku.php?id=en:n%C5%93ud_dos#fn__5) to handle this file.
QuoteRoutines handling the ouput file
As requested by the operating system (and like AMSDOS), only one file at once can be opened as output, which makes the implementation on these routines quite simple.
The DOS nodes can use 80 bytes at offset +&3806) (https://unidos.cpcscene.net/doku.php?id=en:n%C5%93ud_dos#fn__6) to handle this file.
This is usually enough to store all the information you need for internal file management.

It is important not to mix areas used for input and output files because one could be opened on your node but the other on another node.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 09:42, 15 February 24
What do you mean by "at offset"?  Offset to what?

ExamineNext, Not Examine. 

A7E0   00 00 00 00 5B 52 4F 4F 54 DD 00 00 00 00 00 00

|DIR, HL = A7E4, i.e. points to [ROOT
CAT, HL = A7E5, i.e. points to ROOT

In the streamer node, there is no real filesystem, it is a fake one.  So, I look at the requests in turn to present a fake filesystem to the user.

If ROOT, then I display FILE1.  If FILE1 then I display FILE2, If FILE2 then I display FILE3, etc...   The only oddity is the value of HL on entry to "ExamineNext".
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: OffseT on 14:11, 15 February 24
Quote from: zhulien on 09:42, 15 February 24What do you mean by "at offset"?  Offset to what?
It is explained in the documentation. See quoted note. ;D
It is relative to the DOS ROM allocated memory area.

Quote from: zhulien on 09:42, 15 February 24ExamineNext, Not Examine. 
In ExamineNext, HL is for output. It is were you have to store data (filename) corresponding to the next entry. It does not contain any input information.

First, Examine is called to start a directory content examination (with HL = 0 and DE = pointer to the directory to examine).
Then ExamineNext is called as long as you provide entries from that directory.

Also, like for file input/ouput management, you have a specific memory area you can use during the examination session:

Routines analyzing files and directories
Only one analyze at once can be started.
The node can use 80 bytes at offset +&3D07) (https://unidos.cpcscene.net/doku.php?id=en:n%C5%93ud_dos#fn__7) to manage files and directory to examine.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 06:09, 16 February 24
Actually I only need 1 or 2 bytes... I guess I need to read the docs again
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 06:24, 16 February 24
Any chance to add 81 bytes to nvram for the following...

64 bytes for dktronic style up to 4mb (1 byte per 64k bank)
16 bytes for vortex 512k (1 byte per 32k block)
1 byte for multiface 2 (1 byte)

All these ram expansions can then be managed in a better way by the user through a little ram management utility that presents them with the arrays of bytes for them to edit.

- for each block means they don't care and anything can trash them
F reserved for FutureOS
S reserved for Symbos
C reserved for CPM future enhancements
r reserved for a better RAMdisc
P reserved for Primal
s reserved for streamer dos node
G reserved for general usage (better than legacy but not much)
R reserved for the user
(Other letters for consideration in future but not every application requires special ram)

For example a better handling by some OS type application would first check are there any reserved bytes for it, e.g. Primal would check any Ps.  If enough just use the Ps. If there is at least 1 P but its not enough then Primal should display an error to the user and not continue.  If there are no Ps but enough G then Primal would use that instead.  If still not enough G, then it would use - instead. How a software uses the specified RAM is up to them, but they should not trash the other softwares RAM... they can still examine it though.

A better behaved standard application would first check for G and if at least 1 G but not enough then error.  If no G then use -. This will allow newer better behaved apps to not trash legacy apps and vice versa.

If a newly developed app uses its ram like this then the user can still say don't care for the first 512k and be happy that old software likely won't trash the new program if the user still sometimes uses older software, I.e.cpm

-------- 512k dktronics don't care, things can trash this as per the current norm
56bytes following the user can either put - or their preferred other value from above.
16 bytes following for vortex 512k
1 byte for multiface 2
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 09:48, 16 February 24
Thinking a bit more, make L for legacy instead of -.  If an OS type program has its own RAM such as P, then it can use P and G but it can be confident no other program will corrupt P.

This would allow eg.. Symbos to execute AMSDOS applications, FutureOS to execute AMSDOS applications and both can return without corruption of their own reserved S and F. Almost a perfect World, able to have all those OSs coexist in harmony.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: andycadley on 10:10, 16 February 24
User: Why doesn't Symbos run on my Amstrad. I have a 4MB memory module?

Support: You have to go run this other program first and change a bunch of letter to S.

User. Weird. Okay I did that and it works. But now when I run FutureOS it just crashes at startup.

Support: Right, what you've done there is given some of FutureOS memory to Symbos and now it's in a weird state. You'll need to run this other utility to clear all the memory back to a known good state every time you change configuration.

User: Ok, now my notes app forgets everything just because I want to switch between two programs and have to give both of them large configuration. Isn't there a way FutureOS could know and reset itself?

FutureOS developer: I'll have to add a bunch of validation to verify at startup that all the RAM I want to use hasn't changed since I last run it. Sorry it's now really slow to start up.

MagicApp developer: Why can't I get a letter to reserve memory? I've got some half working code for a menu and at least one other person said they might use my program.

User: Bugger this for a laugh, I'm just going to get a C64. All I want to do is play games and run the occasional utility.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: GUNHED on 17:31, 16 February 24
FutureOS support: FutureOS supports the full 4 MB of RAM, so it's fine to use the last 1, 2 or 3 MB for it. No other OS does this anyway, so there shall be no interference.  ;) :)

FutureOS CEO: Hi Zhulien! Great idea, all that stuff at the same time. Nice!  :) :) :)
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 18:00, 16 February 24
Quote from: andycadley on 10:10, 16 February 24User: Why doesn't Symbos run on my Amstrad. I have a 4MB memory module?

Support: You have to go run this other program first and change a bunch of letter to S.

User. Weird. Okay I did that and it works. But now when I run FutureOS it just crashes at startup.

Support: Right, what you've done there is given some of FutureOS memory to Symbos and now it's in a weird state. You'll need to run this other utility to clear all the memory back to a known good state every time you change configuration.

User: Ok, now my notes app forgets everything just because I want to switch between two programs and have to give both of them large configuration. Isn't there a way FutureOS could know and reset itself?

FutureOS developer: I'll have to add a bunch of validation to verify at startup that all the RAM I want to use hasn't changed since I last run it. Sorry it's now really slow to start up.

MagicApp developer: Why can't I get a letter to reserve memory? I've got some half working code for a menu and at least one other person said they might use my program.

User: Bugger this for a laugh, I'm just going to get a C64. All I want to do is play games and run the occasional utility.
No you don't need to do anything if you like things to be as they are, but if you do want to control what ram is allocated to what, you have a choice. The main issue is that old software without memory management of any type trashes everything else in extended ram, which can survive a reset a day newer software if everyone follows some guidelines and NVRAM has a reasonable ability to facilitate would work nicely together.

Wouldn't you like your future RAM disc unidos node of x capacity not trashed by e.g. Symbos or FutureOS or even discology?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 18:02, 16 February 24
Quote from: GUNHED on 17:31, 16 February 24FutureOS support: FutureOS supports the full 4 MB of RAM, so it's fine to use the last 1, 2 or 3 MB for it. No other OS does this anyway, so there shall be no interference.  ;) :)

FutureOS CEO: Hi Zhulien! Great idea, all that stuff at the same time. Nice!  :) :) :)
Yes FutureOS and Primal / MCP will conflict, and enhancements i am in the middle of making for streamer unidos node - of course I can trash other software in RAM, but it kinda sucks.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: andycadley on 19:16, 16 February 24
Quote from: zhulien on 18:00, 16 February 24
Quote from: andycadley on 10:10, 16 February 24User: Why doesn't Symbos run on my Amstrad. I have a 4MB memory module?

Support: You have to go run this other program first and change a bunch of letter to S.

User. Weird. Okay I did that and it works. But now when I run FutureOS it just crashes at startup.

Support: Right, what you've done there is given some of FutureOS memory to Symbos and now it's in a weird state. You'll need to run this other utility to clear all the memory back to a known good state every time you change configuration.

User: Ok, now my notes app forgets everything just because I want to switch between two programs and have to give both of them large configuration. Isn't there a way FutureOS could know and reset itself?

FutureOS developer: I'll have to add a bunch of validation to verify at startup that all the RAM I want to use hasn't changed since I last run it. Sorry it's now really slow to start up.

MagicApp developer: Why can't I get a letter to reserve memory? I've got some half working code for a menu and at least one other person said they might use my program.

User: Bugger this for a laugh, I'm just going to get a C64. All I want to do is play games and run the occasional utility.
No you don't need to do anything if you like things to be as they are, but if you do want to control what ram is allocated to what, you have a choice. The main issue is that old software without memory management of any type trashes everything else in extended ram, which can survive a reset a day newer software if everyone follows some guidelines and NVRAM has a reasonable ability to facilitate would work nicely together.

Wouldn't you like your future RAM disc unidos node of x capacity not trashed by e.g. Symbos or FutureOS or even discology?
But the use cases are so niche that it's more effort to manage and support than it is worth. It'd be much easier for such applications to just support suspending themselves to a high performance storage medium whenever appropriate (including on CTRL+SHIFT+ESC) - then everything can use all the RAM available and it'll always "just work"
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 05:15, 17 February 24
Quote from: andycadley on 19:16, 16 February 24
Quote from: zhulien on 18:00, 16 February 24
Quote from: andycadley on 10:10, 16 February 24User: Why doesn't Symbos run on my Amstrad. I have a 4MB memory module?

Support: You have to go run this other program first and change a bunch of letter to S.

User. Weird. Okay I did that and it works. But now when I run FutureOS it just crashes at startup.

Support: Right, what you've done there is given some of FutureOS memory to Symbos and now it's in a weird state. You'll need to run this other utility to clear all the memory back to a known good state every time you change configuration.

User: Ok, now my notes app forgets everything just because I want to switch between two programs and have to give both of them large configuration. Isn't there a way FutureOS could know and reset itself?

FutureOS developer: I'll have to add a bunch of validation to verify at startup that all the RAM I want to use hasn't changed since I last run it. Sorry it's now really slow to start up.

MagicApp developer: Why can't I get a letter to reserve memory? I've got some half working code for a menu and at least one other person said they might use my program.

User: Bugger this for a laugh, I'm just going to get a C64. All I want to do is play games and run the occasional utility.
No you don't need to do anything if you like things to be as they are, but if you do want to control what ram is allocated to what, you have a choice. The main issue is that old software without memory management of any type trashes everything else in extended ram, which can survive a reset a day newer software if everyone follows some guidelines and NVRAM has a reasonable ability to facilitate would work nicely together.

Wouldn't you like your future RAM disc unidos node of x capacity not trashed by e.g. Symbos or FutureOS or even discology?
But the use cases are so niche that it's more effort to manage and support than it is worth. It'd be much easier for such applications to just support suspending themselves to a high performance storage medium whenever appropriate (including on CTRL+SHIFT+ESC) - then everything can use all the RAM available and it'll always "just work"
Absolutely not.  So in your mind shelling out to basic from futureos and running a program that wants to use extra memory is niche?

In any case, people want new software and hardware and this feature will be so super useful for my software that is optional for anyone to even care about, heck why you want your program that requires extra ram to not trash your ram disc anyway, that would be stupid...
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Cwiiis on 10:24, 17 February 24
While I agree with Andy that the far more reliable thing to do would be save all state to mass storage, if we are looking for a method of sharing memory, I think it would make more sense to add a kernel allocation function than to rely on every individual app to correctly implement a specific scheme.

I would suggest two functions, malloc and free, something like this;

malloc - BC = size, returns HL = address, carry set on failure
free - HL = address, carry set on failure

It would be up to the implementation how to track allocations, though I would suggest, off the top of my head, using a word at the start of allocated regions to indicate size, with the MSB set to indicate whether it's allocated. Allocating would involve checking this word and using it to jump around to find a large enough contiguous chunk. The allocation space would need to be pre-filled with decreasing words till the end of allocatable memory (with a max 32K segment). Freeing would need to check and possibly combine with the next free chunk when fixing up the prefix word.

This would break very easily with a badly behaved app, but I don't think that's too important to think about given we don't have virtual memory or memory protection of any kind anyway...
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: andycadley on 10:41, 17 February 24
"Program that wants to run other, incompatible, program, but needs to preserves it's own state, in case it gets run again, although not if the user actually switches off the machine because then it wasn't important enough "

Yes, I'd say that's niche.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: andycadley on 10:44, 17 February 24
Quote from: Cwiiis on 10:24, 17 February 24While I agree with Andy that the far more reliable thing to do would be save all state to mass storage, if we are looking for a method of sharing memory, I think it would make more sense to add a kernel allocation function than to rely on every individual app to correctly implement a specific scheme.

The thing is, alternative operating systems already do provide this for their own applications. One Symbos application won't use memory from another while they're running etc.

But when you try to extend this between different operating systems, it just doesn't work and doesn't make any sense. In the same way that if I was dual booting Linux and Windows, it'd be stupid to have to tell each one which portion of RAM they can use.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Cwiiis on 10:54, 17 February 24
Quote from: andycadley on 10:44, 17 February 24
Quote from: Cwiiis on 10:24, 17 February 24While I agree with Andy that the far more reliable thing to do would be save all state to mass storage, if we are looking for a method of sharing memory, I think it would make more sense to add a kernel allocation function than to rely on every individual app to correctly implement a specific scheme.

The thing is, alternative operating systems already do provide this for their own applications. One Symbos application won't use memory from another while they're running etc.

But when you try to extend this between different operating systems, it just doesn't work and doesn't make any sense. In the same way that if I was dual booting Linux and Windows, it'd be stupid to have to tell each one which portion of RAM they can use.

I agree :) But I suppose if Unidos/FutureOS or whatever want to do something that would allow for some agreed level of compatibility between them, this is one suggestion. It's not without precedence either, thinking of DOS/Windows compatibility in the PC world. Though in that case, DOS programs weren't expected to change and I think the more realistic suggestion would be for anything that isn't AMSDOS-like to use memory growing backwards from the end of memory or something and just counting on there not being a collision...
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 14:16, 17 February 24
Quote from: Cwiiis on 10:24, 17 February 24While I agree with Andy that the far more reliable thing to do would be save all state to mass storage, if we are looking for a method of sharing memory, I think it would make more sense to add a kernel allocation function than to rely on every individual app to correctly implement a specific scheme.

I would suggest two functions, malloc and free, something like this;

malloc - BC = size, returns HL = address, carry set on failure
free - HL = address, carry set on failure

It would be up to the implementation how to track allocations, though I would suggest, off the top of my head, using a word at the start of allocated regions to indicate size, with the MSB set to indicate whether it's allocated. Allocating would involve checking this word and using it to jump around to find a large enough contiguous chunk. The allocation space would need to be pre-filled with decreasing words till the end of allocatable memory (with a max 32K segment). Freeing would need to check and possibly combine with the next free chunk when fixing up the prefix word.

This would break very easily with a badly behaved app, but I don't think that's too important to think about given we don't have virtual memory or memory protection of any kind anyway...

MCP does just that but for its kernel in AMSDOS, what about legacy software trashing it? What about other OSs which could also have the benefit of not being trashed? What about other resident non ramdisc software?  If you can think of a better way for all these to share memory suggest it.  NVRAM in unidos has a really good opportunity to facilitate it.

But we do have virtual memory and legacy software could be patched but that is not trivial. We also have some memory protection... to a degree.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 14:26, 17 February 24
Quote from: andycadley on 10:44, 17 February 24
Quote from: Cwiiis on 10:24, 17 February 24While I agree with Andy that the far more reliable thing to do would be save all state to mass storage, if we are looking for a method of sharing memory, I think it would make more sense to add a kernel allocation function than to rely on every individual app to correctly implement a specific scheme.

The thing is, alternative operating systems already do provide this for their own applications. One Symbos application won't use memory from another while they're running etc.

But when you try to extend this between different operating systems, it just doesn't work and doesn't make any sense. In the same way that if I was dual booting Linux and Windows, it'd be stupid to have to tell each one which portion of RAM they can use.
I guess you haven't ever checked out FutureOS, it is actually pretty awesome and a lot better than I thought when I looked at it years ago.  In my view I would like software I write to not trash futureos and other RAM... up to you if you don't care, i am not forcing any solution on anyone, I have suggested a solution that users can optionally use that is a workable solution that has no negative effect on anyone who doesn't want to use it.

Its like some people in this forum don't like new things they are not forced to have, how many cool hardwares that people don't need to buy do they complain about? How many people complain about a next generation cpc when they aren't forced to buy one?  Seems counter productive to always be negative and not solve or deliver actual solutions.

Streamer dos node for example, to play samples and have an RTG system for AMSDOS to not lower HIMEM from BASIC.  It needs to store assets in extra memory, sprites, tile maps, sample data for example ideally without trashing other software.  Of course I could have trash a future ramdisc, trash futureos... but why not do it in a friendly way?

How long do you want to wait for something to preserve its 4mb allocated space to sdcard and restore it?
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: Prodatron on 15:42, 17 February 24
This is the UniDOS thread.
Now it has been hijacked and flooded with completely off-topic stuff.

If you like to talk about different stuff, please open an own thread.
Title: Re: UniDOS, the new multi-device AMSDOS replacement
Post by: zhulien on 17:30, 17 February 24
Quote from: Prodatron on 15:42, 17 February 24This is the UniDOS thread.
Now it has been hijacked and flooded with completely off-topic stuff.

If you like to talk about different stuff, please open an own thread.
Yes it is the UniDOS thread and relates to not trashing memory in the UniDOS streamer node.

Fair enough, I am going to trash all RAM... decision made.
Powered by SMFPacks Menu Editor Mod