News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_OffseT

UniDOS, the new multi-device AMSDOS replacement

Started by OffseT, 15:51, 24 January 21

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

zhulien

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




zhulien

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.

zhulien

#177
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.

zhulien

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.

zhulien

#179
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).

zhulien

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.

OffseT

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:

  • Persistency not working because Nova node could not properly store infos in Nova card.
  • FatFs failing because it could not use Nova either (when detected, it uses Nova instead of the main memory).

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

OffseT

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.

OffseT

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.

zhulien

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.

zhulien

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.

OffseT

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?

zhulien


OffseT

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.

zhulien

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

OffseT

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

zhulien

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.

GUNHED

imho !C should be reserved for the RAM disc to be compatible to RDOS.  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

zhulien

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.

zhulien

In fact, i might have a go at making a RAMDISC, it might be easier to get working than the dropbox-like internet disc

OffseT

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!

zhulien

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


OffseT

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


zhulien

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"


zhulien

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?

Powered by SMFPacks Menu Editor Mod