UniDOS, the new multi-device AMSDOS replacement

[zhulien]

I finally resolved my issue - the documentation is ambiguous and I obviously interpretted it wrongly.

Code Select Expand

;
; 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? 

[zhulien]

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

[OffseT]

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

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?

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.

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? 

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:

Routines 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 +&330⁵⁾ to handle this file.

Routines 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 +&380⁶⁾ 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.

[zhulien]

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

[OffseT]

What do you mean by "at offset"?  Offset to what?

It is explained in the documentation. See quoted note.
It is relative to the DOS ROM allocated memory area.

ExamineNext, 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 +&3D0⁷⁾ to manage files and directory to examine.

[zhulien]

Actually I only need 1 or 2 bytes... I guess I need to read the docs again

[zhulien]

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

[zhulien]

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.

[andycadley]

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.

[GUNHED]

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! 

[zhulien]

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.

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?

[zhulien]

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! 

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.

[andycadley]

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.

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"

[zhulien]

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.

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

[Cwiiis]

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

[andycadley]

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

[andycadley]

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.

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.

[Cwiiis]

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.

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

[zhulien]

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

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.

[zhulien]

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.

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?

[Prodatron]

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.

[zhulien]

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.

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.