• Please review our updated Terms and Rules here

Networking(sort of) to a File Server (sort of)....

MykeLawson

Experienced Member
Joined
Mar 21, 2014
Messages
396
I'm taking a break from finishing my suite of RAMdisk applications since I purchased an old IBM PS/2 8560. It now has a dual RS-232 card and I'm hooking each port to a serial port on each of my CP/M machines (one with STB bus and the other is S-100). The PS/2 will be my 'file server' (PS/2 Com Ports vs. BASIC - https://forum.vcfed.org/index.php?threads/ps-2-com-ports-vs-basic.1244188/#post-1330895). Since I haven't a clue about 80286 assembly code for use on an old PS/2, I am writing the file server application in BASIC. I have four routines planned; get the date, get the time, get a disk directory, delete a file, save a file, and load a file. So far, the first four are working great when I use a dumb terminal as a pseudo-CP/M machine.

So now it will be time to shift gears back to the CP/M machines to write the assembly code to communicate with the fileserver instead of the dumb terminals I use now. Given the commands are just ASCII characters I send to the file server, if should be fairly easy. Like the command to get the date is just '<<DTE'. Then the server sends back ten ASCII characters that I print to the screen. Same for the time except it's just eight characters. The directory command just goes over, the file server creates a directory as a text file, and ships the ASCII characters back over and they are displayed. You get the idea.....

Anyway, if anyone is interested, I attached the BASIC code I have so far.... And I'll post the suite of CP/M client tools as I write them.

 

Attachments

  • MAIN3l.txt
    11.3 KB · Views: 7
Look into CP/NET, the original CP/M network. The Digital Research reference implementation was over serial ports. It used an "NDOS" which layered on top of the BDOS to perform various BDOS function to network servers. Servers could be MP/M or any OS that one could write a server in. I have a server written in JAVA that has been used on Windows, Linux, and MAC.
 
It is a working design from which you can learn. And if you follow their protocol then what you build can interact with what others have.
 
Well, time for an update. I can now reliably get the date and time from the server, and a disk directory, and delete a file from the server. I'm working on the program to read a file from the server and put it in memory at 0100h for CP/M to use. I guess I should add a prompt to the user to either run it by jumping to 0100h or return to CP/M in case I want to do something else with it; ie. save it to disk, or save it to the RAMdisk......
 
Have you heard of ULCNET? Byte Magazine published a Networking issue (Oct 1981 issue at: https://archive.org/download/byte-magazine-1981-10/1981_10_BYTE_06-10_Local_Networks.pdf.) On page 50 (page 52 of the PDF,) there is an article about networking multiple computers over a multi-drop RS-232 network. This is for disparate computers, with different HW and SW and even different OSs. In its simplest form, it requires a single diode for each port. From there the authors go on to present better/faster hardware (but still nothing more than an FET and a couple op amps with a handful of passives.) They then go on to describe a layered networking protocol, similar to our modern OSI model of networking. They even go up to error recovery. They do not give any actual code (so you can still write your own,) but give enough information that you can do the programming.
 
Thanks Art. At this point, given the machines I need (want) to fiddle with), having the two CP/M machines connect to each of the two RS-232 ports of my PS/2 works for what I want. I have two more programs to write to be able to save & load programs from the PS/2. This is working similar to the first computer network I ever ran at home, the '$25 Network'.
 
Digital Research provided example CP/NET code for ULCNET, as well as simple point-to-point (star topology) RS232.
 
There is a good article on ULCnet in BYTE magazine, October 1981 (pg 50...). It seems to be a good discussion of the hardware. It seems that various companies may have expanded on the idea and enhanced it in some way. For example, Kaypro KayNet seems to have provided a way to switch between standard serial port and an enhanced network port (so one doesn't totally lose the normal use of the serial port). KayNet also seems to be using a special Z80-SIO synchronous serial protocol, instead of standard Async RS-232.
 
It is interesting piecing together a history of ULCNET from materials I can find and the few memories I have of it. In the BYTE article (extracted here: http://sebhc.durgadas.com/ulcnet-byte-oct81.pdf), Pacific Polytechnical Corp (just "across the [Monterey] bay" from Digital Research) introduces the idea of a "ULCNET" (unencumbered) but provides no standards for hardware or software. Eight months later, Orange CompuCo has acquired a trademark on "ULCnet" and is selling what appears to be a version for Async Serial RS-232. A year later, Orange CompuCo is selling (e.g. KayNet for Kaypro) a version that requires Z80-SIO-compatible hardware and uses a synchronous serial protocol (incompatible with the previous version). And here (https://retrocmp.de/kaypro/kay-p2_hrdw.htm#kaynet) we have evidence of KayNet hardware that is supposedly made by Centram Systems (which created networking for Apple computers and was later bought by Sun MicroSystems). I'm not finding evidence of any high degree of standardization (interoperability), as is typical of that era. Nothing like today's Ethernet, TCP/IP, NFS, etc. So I get the impression that "ULCNET" is more of a broad idea rather than a specific implementation/standard.
 
One final comment on ULCnet. Looking over the CP/NET code from DRI I am reminded that there is very little information about Orange CompuCo's ULCnet there, as that code must be linked with CompuCo's proprietary library to do the actual sending and receiving. So, without CompuCo's software, not much can be determined. One mystery is how did CompuCo address a message to a specific node, as they seem to discard the CP/NET DID when sending. Perhaps their network topology was very limited, only allowing one "server" - which could then assume all messages are intended for it.
 
Yeah, I took a look at that, that ULCnet (Universal Low Cost Network, not Ultra Low-Cost Network) is a proprietary format networking system based on hardware from a company called range Compuco. It appears to be similar, but I could not find anything to specifically state that.

Still interesting though - even if I have to guess the hardware.
 
Also interesting is that I found that the "KayNet" photos posted earlier are not actually KayNet but something "similar" from Centram Systems called "WEB-NT", using different software (which we do have an archive for). Each of these "solutions", though, is a step (maybe several) away from "Ultra Low Cost". The original BYTE article is using fairly simple hardware (as little as a diode per node), although the software to make it all work is not exactly trivial. These other products are more involved and further away from RS-232 (both seem to be using differential signals, as in RS-422, and synchronous serial protocols).
 
Back
Top