Jump to content
IGNORED

A case for the N: device and a NOS going forward.


Recommended Posts

I really need to make the case for a NOS, and why it would be a massive step forward:

 

In short, it would create a path in which you could not only make a file manager that works entirely over the network, it can leverage the full power of the ESP32 to abstract filesystem operations.

 

Each protocol adapter for N: runs entirely on the ESP32 itself, and can be anything. For filesystems this would be :

 

* FTP
* SMB
* HTTP
* TNFS
* NFS
* SCP/SFTP

 

etc.

 

But other filesystem adapters can be made, e.g. a DISK adapter, which could be pointed either indirectly via a device slot, or directly via path, to (e.g.) an ATR disk image.The ESP32 itself would do all of the abstraction of reading and writing to the ATR; including dealing with all of the filesystem aspects. 

 

This abstraction is critical, because it means that not only do these filesystem access methods not need to be bolted into the Atari code (resulting in a much smaller MEMLO!), it means that this abstraction provides a path for reading and writing from any formatted disk image, regardless of what FMS might be running on the Atari. 

 

So there are two wins here:

 

(1) a NOS, with low memlo that can read and write to anything.
(2) the ability to transparently read and write to anything, file, or image, from any other DOS.

 

This is why I am trying to get people interested in either using or working on N:, a lot of possibilities suddenly open up with this abstraction, thanks to the ESP32.

 

-Thom

  • Like 7
Link to comment
Share on other sites

4 hours ago, Mazzspeed said:

When you say 'any other DOS' Thom, are you talking cross platform compatibility of just on the A8 itself?

...

 

Meaning in any other DOS, if you load the N: handler (NDEV), you suddenly get access to N: and all of its protocol adapters.

 

-Thom

  • Like 2
Link to comment
Share on other sites

Any filesystem compatibility would happen via N: Essentially, the #FujiNet would be reading/writing the ATR image, doing filesystem translation on the device.

 

N:DISK://1/DISK.ATR

 

would access DISK.ATR stored on host slot 1 via the N: device.

 

-Thom

 

Link to comment
Share on other sites

File locks must be implemented if this is to be a true multi-user OS.  We can't have someone else stepping on our file.

This could be a great thing. A RasPi server w/ multiple Ataris booting from / accessing it. That would be AWESOME.

Almost like the TeleVideo TS-816 network server I patched the BIOS to get 2 more hard drives to work. I also integrated NZ-COM into the 'Satellite Operating Systems' that they booted from the server over RS-422. I even changed the Title Screen on the satellite computers (TS-800a, TS-803, TS-802h), etc. to show in 80 column ASCII Network-NZ rather than the original Network-OS.

 

My work on that project included inserting an 'unlock code' into the system before it returned to the CCP prompt to tell the server to release the locks.

BTW, CCP is Console Command Processor. NOT anything [EVIL] that sounds like that. :)

 

Edited by Kyle22
correctness
Link to comment
Share on other sites

12 minutes ago, Kyle22 said:

File locks must be implemented if this is to be a true multi-user OS.  We can't have someone else stepping on our file.

This could be a great thing. A RasPi server w/ multiple Ataris booting from / accessing it. That would be AWESOME.

Almost like the TeleVideo TS-816 network server I patched the BIOS to get 2 more hard drives to work. I also integrated NZ-COM into the 'Satellite Operating Systems' that they booted from the server over RS-422. I even changed the Title Screen on the satellite computers (TS-800a, TS-803, TS-802h), etc. to show in 80 column ASCII Network-NZ rather than the original Network-OS.

 

My work on that project included inserting an 'unlock code' into the system before it returned to the CCP prompt to tell the server to release the locks.

BTW, CCP is Console Command Processor. NOT anything [EVIL] that sounds like that. :)

 

File locking can be done, but isn't needed for a first pass to prove the point.


Also...As a Marxist, I find that last statement factually untrue and offensive. (and lest you actually want to dive with me down that rabbit hole, you might want to think twice before spouting off typical talking points.) (I actually do practice the mantra of "From each according to his ability, to each according to his needs")

 

(If this genuinely offends people, I truly am sorry.)

 

-Thom

Edited by tschak909
Link to comment
Share on other sites

1 minute ago, Kyle22 said:

I want to talk about file systems, not your flawed politics. Why did you even bring politics in here?

We are Americans. Where We Go One We Go All.

No politics. No evil.

Let's talk about computers.

 

You did. I simply called it out. But yes, let's continue talking about #FujiNet.

 

-Thom

  • Like 1
Link to comment
Share on other sites

It's important to understand that all a DOS is typically, is a "D:" handler loaded by the disk boot loader in the ROM.

 

Since 99% of the N: device is on the ESP32, the resulting handler code is (probably going to be in practice) slightly smaller, but with a significant order of magnitude increase in functionality, because we're just passing stuff through to the much more powerful ESP32.

 

-Thom

 

Edited by tschak909
  • Like 1
Link to comment
Share on other sites

Let's take another example, an IMAP adapter.

 

IMAP is the Internet Mail Access Protocol, and was developed by the University of Washington, as a counter-point to the also-used Post Office Protocol, or POP. Where POP functioned as a method of downloading messages from one's inbox to the host computer, IMAP was devised as a way to keep the mail on the mail server, and to be able to use it from multiple computers. 

 

It's a very viable protocol, because it is supported by every major mail system, including Google Mail, and allows you to access your GMAIL inboxes from a preferred email client.

 

An IMAP protocol adapter for N: would abstract the details of accessing e-mail boxes, and provide something that an Atari could easily use. The resulting usage of e-mail would transparently become something closer to a filesystem operation, rather than something explicitly hidden behind the abstraction of an application.

 

(the following are sketches using MEMO PAD)

 

So let's say, from a command processor, to NCD to an IMAP mail box:

WIN_20210504_11_10_12_Pro.thumb.jpg.5a18c6328babd105d16f7ae41e1b7ae4.jpg

 

Doing a directory on this path, would e.g. show the newest messages first

WIN_20210504_11_17_26_Pro.thumb.jpg.6f4e65416a3ac368d0517650894b5d66.jpg

 

At which point, you could get the content of a message by opening it for read:

WIN_20210504_11_21_29_Pro.thumb.jpg.f256f27cb6e0bbf90c0f3eccd918cb08.jpg

 

And you can retrieve the attachment, e.g. via a copy:

WIN_20210504_11_24_17_Pro.thumb.jpg.20a0312e58e21636c5eb77c9c777d2fc.jpg

 

And so on.

 

It becomes trivial, to write an e-mail client if wanted, even in BASIC.

 

-Thom

 

  • Like 7
Link to comment
Share on other sites

So Side Loader, U1MB, things like this, they're all Block Devices?  Or do they intercept at the D1: level?   I presume a future NOS D1: driver could be smart enough to pass requests for drivers it didn't handle down to another OS. Or maybe there could be a block Device loader that would come in on top?

 

Link to comment
Share on other sites

40 minutes ago, cathrynm said:

So Side Loader, U1MB, things like this, they're all Block Devices?  Or do they intercept at the D1: level?   I presume a future NOS D1: driver could be smart enough to pass requests for drivers it didn't handle down to another OS. Or maybe there could be a block Device loader that would come in on top?

 

all good areas for research. The brick wall though is that #FujiNet can't be a device master.

 

-Thom

Link to comment
Share on other sites

34 minutes ago, tschak909 said:

all good areas for research. The brick wall though is that #FujiNet can't be a device master.

 

-Thom

Could Fujinet be device master with a hardware re-design?  Are there enough I/O pins for this? Or maybe a similar chip that could do it?  Would just be so much easier to code a DOS in C++.

Link to comment
Share on other sites

short answer....maybe? in our case, we're out of I/O pins, and the I/O pins we have, can't be repurposed to make it possible to become a bus master.

 

This is something that somebody is just going to have to break out a bread board and try. :)

 

-Thom

 

  • Like 3
Link to comment
Share on other sites

I guess I'm not quite clear on what it is you want. I thought from your FB post, all the protocols would be written in C and run on the ESP32, so that in essence the NOS running on the Atari would be nothing more than a CLI interface that issues the commands to the ESP32 to Open File, Open Email, whatever the function is. Here though, it sounds like you're talking about protocols running on the Atari and talking to the protocol adapters on the ESP32. Which is it ?

Link to comment
Share on other sites

1 hour ago, Alfred said:

I guess I'm not quite clear on what it is you want. I thought from your FB post, all the protocols would be written in C and run on the ESP32, so that in essence the NOS running on the Atari would be nothing more than a CLI interface that issues the commands to the ESP32 to Open File, Open Email, whatever the function is. Here though, it sounds like you're talking about protocols running on the Atari and talking to the protocol adapters on the ESP32. Which is it ?

all the protocols run on the esp32, and provide a clean SIO (and CIO) interface to the Atari. It does indeed make the NOS really simple, just the N: CIO handler, and a command processor :)

 

-Thom

 

  • Like 1
Link to comment
Share on other sites

38 minutes ago, tschak909 said:

all the protocols run on the esp32, and provide a clean SIO (and CIO) interface to the Atari. It does indeed make the NOS really simple, just the N: CIO handler, and a command processor :)

 

-Thom

 

Well if that's all it is, someone could probably knock it out in Action! fairly easily.

Link to comment
Share on other sites

  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...