Needed: A kernel driver for the FujiNet Network device.

[tschak909]

To those working on SpartaDOS X Upgrade Project, ( @drac030 et al )

There are now more than 5,000 FujiNet devices out there. 

 

These devices work with the majority of available Atari DOSes. 

 

While SpartaDOS X can use the virtual disks (D:) and printers (P:) exposed, the CLI can't talk to "N:" via the NDEV.COM handler, which is the Network device, because it conflicts with one of the disk drive mappings.

 

While SDX can use the N* command line tools to do things like copy files (these tools talk to SIOV directly), this is less than ideal.

 

So one of two things should happen:

 

(1) patch SDX so that N: is passed through as a CIO device, when NDEV.COM is loaded.

(2) write a kernel driver to expose N: functions to SDX.

 

For the latter, the source code to the N: handler is here:

https://github.com/FujiNetWIFI/fujinet-nhandler

 

I've asked this before, but dozens of people have now asked me over the last four years for how to handle this.

 

-Thom

[_The Doctor__]

@tschak909

 

N: would not work, but NTF1: would or even NTFA: etc... DNTFA:

N is Nul device in SpartaDOSX using units 1-3

if starting with N causes an issue find another Letter not in use for other abbreviated devices etc.

Device FujNet A: DFNTA: FNTA: etc.

 

Devices.. currently

DSK, CLK, CAR, CON, COM, PRN, NUL, PCL.

Three of them are file-oriented a level down: DSK, CAR, PCL.

and in the lower level In theory, every device can have up to 15 units,
although most of the devices contain only one. Devices with multiple units currently are
DSK, NUL, PCL

 

try DSK1: NUL1: PCLA: or possibly letters A thru O

 

Accessing the 'Kernel' Through CIO
The 😧 device available through the CIO with SDX is not just the disk drive handler; it is
the handler for the SD 'kernel'. Any 'Kernel' device may be accessed through the CIO
from any application by preceding its name with D. For example,
OPEN #3,8,0,"DPRN:"
will open the printer for output.
This also means that D4:, DD:, DD4:, DDD:, DDSK4:, and DDSKD: all refer to drive #4.
When referring to a device other than a disk drive or the CAR: device, the fname.ext
part of the syntax is ignored. If this confuses you just ignore it and use D1: - D9:, E:, P:,
R:, and so on as you would with any other DOS. Remember that drives J: to O: can only
be accessed by letters, e. g. 'DO:' for drive 15.

 

Device DiSK C  DDSKC: etc.

Maybe if you follow the DXXX# convention you might have more success? DFNTA:

 

older disk based SpartaDOS is a bit different to SDX or current SDX

Edited April 11, 2023 by _The Doctor__

[flashjazzcat]

That's the kernel device name taken care of, then (although 'NET:' seemed the most obvious choice to me); just need the kernel driver written and we're done.

 

[drac030]

The kernel driver is the correct solution. "N:" in the CP is disk drive number 14, and it is so not because CP does such a fancy translation, but because it is the proper device code for SDX kernel (device 0, i.e. DSK, unit 14).

 

As I said somewhere else, I am slowly writing the instructions on how to write a kernel device driver for SDX, and I hope to have a preliminary version of this document soon. However, judging from the response to the previously published preliminary PDF on writing the SIO drivers (which are really simple in comparison), this would not help much.

 

I myself do not have FujiNet. As far as I know, @trub has (or was about to have the last time we were talking about it), and he was planning to write the device driver, but what happened to these plans, I do not know.

 

Anyway, if someone wants to know, how SDX kernel device drivers work, I recommend taking a look at the source code of SIO2BSD:

 

http://drac030.krap.pl/en-inne-pliki.php

 

specifically the "PC Link" section. It is basically one big function acting on the PC side as a server for the Atari acting as a client via the PCL: device driver.

 

(Note that, contrary to a myth perpetuated e.g. by Altirra, which lists PCLink under serial devices, PCL: is de facto not a serial device per se: SIO is currently only used as a transport layer, because there is nothing else to communicate with the PC side than a SIO2PC).

 

Here:

 

http://atariki.krap.pl/index.php/DOS2DOS#Tabela_funkcji

 

there is a description of the PCL: device driver functions, which are the same as the functions of the SDX kernel device driver. It is written in Polish, but the Google translator should do.

 

The function numbers listed are reserved for the functions listed (especially 0-7 require a valid handle, others do not), but generally speaking the range of function numbers is from 0 to 255, where functions 0, 1, 7, 8 and 9 are reserved for character devices (such as NUL:, CON:, PRN: etc.), 0-31 are reserved for file system devices (DSK:, CAR:, PCL: etc.), 250-255 for internal use, 100-111 are reserved for the CLK: clock special device, and the rest is open for definition for other special devices.

 

A kernel device driver, depending on what a device it is implementing, must define a range of these functions to be able to respond to kernel calls.

 

In any case I can assist with the SDX side of things.

Edited April 11, 2023 by drac030

[drac030]

Here is the said documentation:

 

SDX_Progr_Guide_450_EN_1_00-preliminary.pdf

 

The kernel drivers are described in chapter 23. This is a preliminary version of the document, so if anyone spots anything to fix, or any additional stuff that needs explaining, please let me know.

 

 

[flashjazzcat]

1 hour ago, drac030 said:

Here is the said documentation

Great. Reading with interest.

[Faicuai]

On 4/11/2023 at 10:19 AM, drac030 said:

I myself do not have FujiNet.

In the event that you are interested (or have some bandwidth) to put some work on a kernel-driver, I can send you a Fujinet v1.7 (yours to keep). 

 

FYI, If I could, I could also send you a VoiceBox-II (Votrax SC-01-A) for its SDX driver too (one of its supplied drivers is already cooked on $4000-$7FFF address space) so you we can top it off with fireworks (but I don't have a substitute, very unfortunately).

 

First offer firm, just let me know if you are interested (PM).

 

 

[drac030]

@Faicuai Thanks for the offer, normally I probably could hardly resist, but my spare time is so tight this year, that I probably will have to spend all my vacation sitting home at the computer. And that computer, unfortunately, will not be Atari with an assembler, but a PC with a wordprocessor.

 

Of course, I will do some programming, but I just do not have time for new projects.

 

That said, I also must say that I saw Fuijnet in action once and, how to put it gently, I was not impressed. IMHO its worst handicap is SIO (a parallel PBI version would be most welcome), and it is by design; but apart from that there were visible problems with stability, error handling (every problem was acknowledged by the software with a very informative message: "SIO ERROR"), and well, the only successful operation demonstrated to me was booting DOS XL from the network. This indeed shows that it works, nevertheless I can, and in a much more convenient way, boot DOS XL from my HDD, if I need it for a (weird) reason...

[tschak909]

I am sorry that your experience with FujiNet was less than optimal. All the same, the whole project is deliberately open and public, and we could use your help for making a kernel driver. 

 

I hope you will reconsider, at least some portion of the close to 5,000 user install base would really appreciate it.

 

 

[Faicuai]

On 6/15/2023 at 11:29 AM, drac030 said:

that said, I also must say that I saw Fuijnet in action once and, how to put it gently, I was not impressed. IMHO its worst handicap is SIO (a parallel PBI version would be most welcome), and it is by design;

 

Ok, fair enough.

 

I understand the system-bus vs. serial-bus implications, etc., but I would urge you to consider the broader picture and implications.

 

Here in the U.S., there is a significant 400, 800, 1200XL and 800XL installed base. Only the 800XL has PBI. Only the 800 has both left-and-right cart ports, plus four system slots, etc. I can easily envision a right-cart version of Fujinet with on-board SIO-server and delivering packets at the speed of that bus... but that is only for the 800, and 400 and 1200XL have none of that. However, ALL of them have a SIO bus/port ready-to-go.

 

Then we have the fact that a LOT of content (especially from 1979-1984, critical life-cycle years) is mostly cassette / disk / cart based, and that is what a lot of folks around here would definitely like to recreate, at a minimum. Therefore SIO-peripheral handling is also key.

 

Bottom-line is that Fujinet's current interface (while not exactly matching the transfer speeds neither the system or ethernet can handle), it does address well the means and peripherals typically known or available to most users out there, and it does that in a totally plug-and-play mode.

 

It is networking for the masses, in a simple, straight-forward / plug-and-play manner, plus playing along well with the O/S design and extensibility and off-loading as much as you can from the host's CPU.

 

I think it is worth the try and effort, because it will continue to get adopted (for natural reasons). 

 

 

Edited June 16, 2023 by Faicuai

[drac030]

On 6/16/2023 at 6:06 PM, Faicuai said:

Only the 800XL has PBI.

Also many 65XE and all 130XE. These are the majority of Atari machines in Europe.

 

As you write, the SIO is the least common denominator for all the systems, nevertheless, there is also a reason why Atari went for the PBI: namely, SIO is *slow*. Even at divisor 0, ~12 KB/s is slow in comparison with a basic PBI solution. Yes, the Fujinet has the undisputable advantage that it exists. It however does not seem to work very well, as said above.

[tschak909]

4 minutes ago, drac030 said:

Also many 65XE and all 130XE. These are the majority of Atari machines in Europe.

 

As you write, the SIO is the least common denominator for all the systems, nevertheless, there is also a reason why Atari went for the PBI: namely, SIO is *slow*. Even at divisor 0, ~12 KB/s is slow in comparison with a basic PBI solution. Yes, the Fujinet has the undisputable advantage that it exists. It however does not seem to work very well, as said above.

For you.

 

5,000 active users say otherwise.

 

As for being slow? The lesson we learned is that it's better to be useful, than fast.

 

(and yes, I know what you're going to say, can you go into detail as to what is happening for your use case?)

 

As for the malfunctioning utilities? guess what? the code is available, so they can be improved, and there is a bug tracking system we are actively monitoring.

 

-Thom

Edited June 19, 2023 by tschak909

[drac030]

5 minutes ago, tschak909 said:

5,000 active users say otherwise.

If the user base is so great, then I do not see why it has to be me to write the handler, who even do not have the device. I just wrote the documentation and made it available. I took my spare time to do that, because you asked for that, eventhough I really might have used that time for something else. And, instead of some sort of "thank you", what I get here? Sheesh.

[tschak909]

8 minutes ago, drac030 said:

If the user base is so great, then I do not see why it has to be me to write the handler, who even do not have the device. I just wrote the documentation and made it available. I took my spare time to do that, because you asked for that, eventhough I really might have used that time for something else. And, instead of some sort of "thank you", what I get here? Sheesh.

Thank you for the documentation. 

 

I ask, because I am doing bring-ups of many more platforms than Atari, and just like with the Atari, I am writing not only large swaths of the firmware, I am also writing all the user tools.

 

We place all of this publicly, so that people can help, and again.. Just asking for help.

 

I must add, we chose the SIO port, specifically, because it's everywhere on the Atari, and it gave us a vector to make something widely integrated into the operating system, without special drivers, to deal with a wide variety of functionality. Again, better to be useful, than to be fast.
 

If we had developed a PBI version first, development time would have been significantly longer. I can say this empirically, because it has taken the better part of TWO years to develop a generic 8-bit bus interface for the microcontroller we use (ESP32). It's being developed for the ZX Spectrum version first, and it will create a path to create FujiNets for EVERY SINGLE SYSTEM with a bus slot, including Atari with the PBI.

 

-Thom

Edited June 19, 2023 by tschak909

[Faicuai]

20 hours ago, drac030 said:

Also many 65XE and all 130XE. These are the majority of Atari machines in Europe.

Absolutely, I am very well aware of this, and I knew in advance you would mention this.

 

But if we go down that path, we need to remain honest with ourselves:

1. PBI was never really developed and properly implemented by Atari.
2. XL and XE implementation of PBI physical interface is DIFFERENT (!)
3. XL and XE PBI implementation seems a cost-reduced version of what we saw on 1400XL (no real buffering of address and/or data lines), with no real capabilities of scaleable, host-provided DC power-delivery over the bus (except maybe on the 800/Incognito, with its much beefier internals and Power Supply).
4. Most importantly, TODAY we still lack a common framework on how to handle modern, PBI-based upgrades:
   • We don't even have a common agreement on DC-power budget (for PBI-variants where +5v DC come from the host, including Incognito)
   • We DO NOT have an agreement on (pass-through vs. terminal) configuration of upgrades plugged in the host's back PBI connector.
   • For instance, look at the differences between AVG's PBI-based facilities, Turbo Frezer, SysCheck, and others! 

Don't get me wrong: I am *ALL IN* for using PBI's inherent benefits and performance potential. However, and in the absence of such a common implementation and usage framework, SIGNIFICANT assumptions would have to be made in order to design and implement a device like Fujinet capable of running on Atari's PBI bus, for both US and Europe's installed base, AND at the expense of the large 400/800 installed-base here in the U.S.

 

20 hours ago, drac030 said:

nevertheless, there is also a reason why Atari went for the PBI: namely, SIO is *slow*. Even at divisor 0, ~12 KB/s is slow in comparison with a basic PBI solution. Yes, the Fujinet has the undisputable advantage that it exists. It however does not seem to work very well, as said above.

It is the same thing I personally think about fisher-price Atari DOS 2.x, MyDos, etc. when compared to SDX (I even remember hanging to DOS XL as long as I could just to escape from those basic DOS versions). 

 

And having Fujinet working nicely on SDX (and managing memory efficiently) will only boost and facilitate SDX's use and further adoption, as well. 

 

I guess that's the key point.

 

Edited June 20, 2023 by Faicuai

[+DjayBee]

26 minutes ago, Faicuai said:

And having Fujinet working nicely on SDX (and managing memory efficiently) will only boost and facilitate SDX's use and further adoption, as well. 

Or saying it in @tschak909's words: "it's better to be useful, than fast."

[flashjazzcat]

It's better to be useful AND fast IMO, but in any case, I've decided to have a crack at the driver myself for the express purpose of curtailing this debate.

Edited June 21, 2023 by flashjazzcat

[Faicuai]

On 6/21/2023 at 3:43 AM, flashjazzcat said:

I've decided to have a crack at the driver myself for the express purpose of curtailing this debate.

Will hardly get any better, then (unless Konrad ends up joining the party! 😁).

 

Whenever testing is needed, I have FN-v1.7 here, and will find quality time for it. Have most of the gear needed.

 

If there is anything that needs attention, I will likely find it, and report it ASAP.

Edited June 23, 2023 by Faicuai

[_The Doctor__]

The debate may not get any better but it is remediable. I have faith that an FJC will be able to fashion a few drivers for the SpartaDos (3.xx) (X _4.xx) lines. It might require some changes on the FujiNet side to flesh all functionalities out eventually. You can bet the situation will be measurably and observably better. There is an innate knowledge that has been gained by mucking about in the firmware/filesystems playground. Most don't have that experience, a handful do. FlashJazzCat certainly has and does.

[flashjazzcat]

2 hours ago, _The Doctor__ said:

I have faith that an FJC will be able to fashion a few drivers for the SpartaDos (3.xx) (X _4.xx) lines.

Does the existing N: driver not work with Sparta 3.x? It should.

Edited June 23, 2023 by flashjazzcat

[_The Doctor__]

Watch it work and it won't be long before you will get some idea. It's not exactly on point. Pretty sure if you are taking it to X making it relocatable as to just re locating it would be good. It's a good bet, once you dig in you'll see a number of areas to improve. For whatever reason it doesn't always play nice, fortunately you have a menagerie of drives and devices to give it a proper shake down. Consider this a vote of confidence. I had a few of the device over time and it's been a challenge. I wasn't able to get it to work reliably with BBS Express Pro. In any event, there isn't much to say until you tear into it and give it a look see and go. I recently picked up a 1.6 to try again. Though just after 1.7 was released.

Edited June 24, 2023 by _The Doctor__

[flashjazzcat]

8 hours ago, _The Doctor__ said:

It's a good bet, once you dig in you'll see a number of areas to improve.

I have no doubt about that, but I thought the existing N: driver relocated down to MEMLO anyway. There is a tremendous amount of code whose sole purpose appears to be relocation at run-time, at least. 

8 hours ago, _The Doctor__ said:

Consider this a vote of confidence.

Sure thing; I was just specifically concerned about the Sparta 3.x issues you pointed out, since I wasn't proposing to completely re-write the N: driver as well as producing an SDX kernel driver.

[flashjazzcat]

I can at least verify that Konrad's documentation regarding device name registration and driver initialisation is accurate, and that the example code provided works as described:

Now to make it actually do something.

[flashjazzcat]

Unfortunately I just discovered (as I was about to start fleshing out the disapatcher in the kernel driver) that the N: API is completely lacking the necessary functions to support an SDX kernel driver (GetFirst/Next, acccess to directory and file metadata, etc), so this is clearly going to take a bit of work on both sides to sort out. Since Konrad was asked so many times to write this kernel driver, one assumed the necessary SIO functions were sitting there waiting to be called, but it seems not, unless (hopefully) I have misconstrued or overlooked something. 

 

Edited June 24, 2023 by flashjazzcat

[tschak909]

1 hour ago, flashjazzcat said:

Unfortunately I just discovered (as I was about to start fleshing out the disapatcher in the kernel driver) that the N: API is completely lacking the necessary functions to support an SDX kernel driver (GetFirst/Next, acccess to directory and file metadata, etc), so this is clearly going to take a bit of work on both sides to sort out. Since Konrad was asked so many times to write this kernel driver, one assumed the necessary SIO functions were sitting there waiting to be called, but it seems not, unless (hopefully) I have misconstrued or overlooked something. 

 

Oh, Ok, anything missing we can add in the firmware.

 

-Thom