Computers Overview
Commodore PET
Sinclair ZX80
Sinclair ZX81
BBC Micro
Sinclair Spectrum
Memotech MTX
    About
    Library
    Manuals
    Options
    Photos
    Projects
      CFX
      Hardware Hacks
          MTX Co-pro
          New Keyboard
          New PSU (AC)
          New PSU (DC)
          NFX
          RAM Upgrade
          Video Upgrade
          VRAM Upgrade
      Legacy (1980s)
      MAGROM
      MTXPlus+
      PAL Reader
      PC Keyboard I/F
      Programmers
      ReMemotech
      ReMemorizer
      SDX
      SFX
    Repairs
    Software
    Tools
    User Groups
    Video Wall
Memotech CP/M
Atari ST
PDAs
DEC 3000 AXP
OpenVMS
Raspberry Pi

 

 
 
 

The Memotech MTX Series

MTX Web Server (NFX)

Courtesy of Martin Allcorn & Andy Key

 

OK, nobody is going to attempt to run a website hosted on a Memotech MTX, but the hardware now exists that would make it possible! Back in 2017, Martin and I had discussed the feasibility of adding a network interface to a MTX computer, but at the time, it was just a pipe dream - or so I thought . . . .

Design & Build - NFX Version 1
In mid June 2017, Martin gave me a heads up on something new that he'd been working on in the background.

He sent these photos showing a mysterious new component added to a pretty bare piece of prototyping board with a Compact Flash card reader attached and a ROM identified as "NFX".

The mysterious component turned out to be a Wiznet W5100, a Hardwired TCP/IP embedded Ethernet controller. Supporting documentation can be found on the Wiznet site, including :-

  Datasheet
  Datasheet Errata
  Application Note
  Hardware Design Guide
  I/O Library (Driver)  
As noted on the Wiznet site, the main features of the W5100 are:
  • All-in-one Ethernet Controller
    • Hardware TCP/IP, MAC & PHY
  • Fully hardwired network protocol
  • Direct & Indirect Bus and SPI for Host Interface
  • Stable Data Communication
"W5100 suits users in need of stable Internet connectivity best, using a single chip to implement TCP/IP Stack, 10/100 Ethernet MAC and PHY. Hardwired TCP/IP stack supports TCP, UDP, IPv4, ICMP, ARP, IGMP, and PPPoE."

Martin was attempting to provide the MTX with Ethernet connectivity!

At this stage, the hardware was connected to a cut-down CFX-II board (which uses an 8 bit CF connection) running a copy of the SDX BASIC ROM. The W5100 was configured to use Z80 I/O addresses 160-167 decoded by the HCT138. (4 Ports are being used, but for simplicity, each is presented twice.)
Port 160 (164) is the control port, the W5100 is setup in indirect mode.
Port 161 and 162 define the memory address in the W5100's RAM
Port 163 is the data

Martin was quickly able to get the MTX communicating on the network, here you can see that the device has been configured with IP address 192.168.1.253 and is happily responding to pings from a Windows command prompt.
However, Martin realised that getting the hardware working was the easy part (his words) and that writing the software to get best use from the device was going to be a challenge for him and suggested that the "real programmers" in the Group might be best placed to take the software further.

I suggested that Andy's skills in that area could be leveraged. It was convenient that Memofest 2017 was coming up. Hopeful that Andy could work his programming magic on the NFX hardware, Martin presented the NFX prototype board to Andy, along with a challenge to get an MTX on the internet . . . .
By the time that Memofest 2018 came around, Andy had indeed been able to use NFX to get an MTX computer communicating over TCP/IP, to such an extent that he had a working webserver that was demoed during the event.

For full details of the clever coding behind Andy's webserver, see his Memofest 2018 report and his dedicated NFX page.

NFX.COM provides the NFX hardware with standard TCP/IP functionality, supporting the chargen, echo and http services.
 
The prototype NFX board attached to a Martin's MTX (with orange coloured function keys from a BBC Micro).

The display shows the output from Andy's NFX.COM program as it serves web pages to a network attached PC.

(Photo courtesy of Andy Key)
Screen output from NFX showing activity of the services, including
http_listen listening for http requests
http_connected a connection has been established
http_do_get remote has requested a file
http_send_ok_response successful send
http_disconnect connection closed
The server supports up to 4 simultaneous connections, here, two are http services and you can see interleaving of messages from the different services

Software Development - NFX.COM

Andy has implemented three network services in his NFX code :

Service Port Description
chargen 19 Character Generator. A debugging tool that causes the server to send a stream of character data to the client.
This can be demonstrated under Windows using telnet connected on port 19:
telnet 192.168.1.123 19
(Type <ctrl><]> to interrupt the chargen stream, then quit to exit telnet)
echo 7 Echo Service. A debugging tool that causes the server to echo characters received from the client.
This can be demonstrated under Windows using telnet connected on port 7:
telnet 192.168.1.123 7
(Type <ctrl><]> to stop sending characters, then quit to exit telnet)
The echo service is also responsible for responding to network ping commands and can be used to confirm that NFX is "alive". (Although, NFX does not report that the echo service is connected in the same way that is does when echoing text over Port 7.)
http 80 A simple web server - this is the really useful one! As well as giving the MTX the ability to service web file requests, the http protocol allows files to be transferred to and from a PC.

On his website, Andy demonstrates the use of curl to interface with the http service running on the MTX. curl is a command line tool used for transferring data using a number of network protocols, including http. (Windows versions of curl are available from the haxx website.)

The http service provides limited file transfer capabilities such as read, write and delete :

Function curl syntax
write file from PC curl -X POST --data-binary @index.htm http://192.168.1.123/index.htm
delete file from MTX curl -X DELETE http://192.168.1.123/index.htm
read file from MTX curl http://192.168.1.123/index.htm
read and save a file curl --output <destination file> http://192.168.1.123/<sourcefile>

Martin recently sent me one of his prototype boards for me to try out. I can confirm that it works well. My original goal of having network connectivity to the MTX was to facilitate file transfer over my local network and at this point, NFX is able to do that.

I created a test html page called index.htm and was able to "post" it to the CFX CF card on the MTX using the syntax above.

The NFX web server was able to display the file in my Windows browser as shown here.

Reading files using the http service is supported, but curl normally expects the file to be displayed on the user's screen, or more accurately, on stdio, rather than saved to disk, but save to disk is possible by specifying additional parameters in the curl command.

A non-printable file, such as a binary, can be saved from your browser in the normal way, e.g., specifying NFX.COM in the URL will display the normal dialog that allows the file to be saved or executed - though attempting to run the file is obviously a bad idea!

Limitations

The http service does not support the use of wildcards and does not support getting a directory listing. Better support for file transfer would require that an ftp service was created in NFX, but that may not be feasible.

The IP address of the server is hard coded into NFX. The chosen address (192.168.1.123) falls right in the middle of the DHCP range I use for my network. I will either need to modify the address in the source, or to give more flexibility, try to modify the source to allow the network parameters (IP address, subnet mask and default gateway) to be specified on the command line or in a configuration file.

It is not possible to break out of the program on the MTX, probably due to interrupts being disabled, the only way to stop the services is to restart the MTX. That's not much of an issue, but being able to gracefully stop the program, perhaps by sending a command to the server, would be a nice addition.

Hardware Development

Only two instances of the Version 1 prototype exist, courtesy of Martin, Andy has one and I have the other. NFX was never intended to be a standalone product, it was essentially a proof of concept to prove that network capability could be added to one of our "disk drive" add-ons for MTX or MTXPlus+.

As of August 2020, it has not actually made it into any other products, but the design has continued to evolve. The prototype NFX  boards are the absolute minimum required to get the "net" up and running. Andy's NFX software works with either, as the major difference between the 2 Wiznet boards is the removal of the unused (by NFX anyway) memory mapped mode.

Design & Build - NFX Version 2
The Version 1 boards use a WIZ811MJ network module, which used a W5100 self contained TCP/IP controller.

Version 2 of the design uses the newer WIZ810SMJ, which has the W5100S fitted

The Version 2 prototype board. There is one 8k ROM image, which is running a modified CPM BIOS using the VDP for a 40 column display.

The CF is connected an 8 bit IDE interface on the same I/O ports as CFX-2. The actual connections for the IDE and Net module are very similar. The only other components on the board are a 74HC138 doing the I/O decode for IDE and Net and a 3.3v LDO to power the net module.

The 8 bit IDE interface uses ports B0 to B7, and the W5100 uses 4 ports A0 to A3, (those are shadowed on A4 to A7 due to decode limitations). (The jumper on the test board selects ports 90-93 instead, suggested by Andy to avoid the I/O clash with Rememorizer's floating point hardware.)
Theoretically the NFX code should run from any MTX filing system, it's not restricted to CF, CF just happens to be easy to build for.
Solder side of the Version 2 prototype board.

It's not as complicated as some of Martin's other wired boards, but it's still a lot of work - done to Martin's usual high standards.

It's so much easier to let Martin do the prototyping & testing, then just get PCBs made :-)
   
   

Software Development

To my mind, the limitations mentioned above, mainly the fixed IP address and being unable to get a remote directory listing, compromised the effectiveness of NFX and deserved some attention. Being unable to tackle these issues myself, I asked for help on the Memotech forum.  Bill Brendling rose to the challenge and was soon able to make significant enhancements to NFX.COM.

 

 
The first enhancement that Bill implemented was having the http server return a file listing from the CFX directory.

If no filename, such as index.htm, is appended to the IP address, NFX will return the directory listing in html format.

Common internet related file types such as HTM, CSS, JS, GIF, PNG, JPG, TIF, or files recognised as text, can be displayed by selecting the filename. Selecting other filenames, including executable (COM) files presents the usual browser dialog which allows the file to be saved.
The filenames can also be retrieved using curl

e.g., curl http://192.168.1.32/

If a filename is entered, it will be "printed" to the console, or, the output can be directed to a file

e.g., curl --output nfx.log http://192.168.1.32/nfx.log
Observant readers will note that the MTX now has address 192.168.1.32, this is possible because Bill has implemented reading the network parameters from a configuration file at startup.

nfx.cfg can contain up to 4 parameters which should be entered in the order and format shown (without the parameter names)
Parameter Example Comment
IP address 192.168.1.32 mandatory
Subnet Mask 255.255.255.0 optional
Default Gateway 192.168.1.1 optional
MAC Address 00:08:DC:4E:46:58 optional

If only the IP address is to be changed from the defaults, lines 2-4 may be omitted. If nfx.cfg does not exist, defaults will be used.
 
   

 

MTX File Write Speed

Reading files from the MTX to a PC is pretty fast, but sending files the other way is exceedingly slow, expect something like 0.5-1k per second! That speed would likely be unacceptable for frequent use, but, for occasional use, it may be acceptable. The bottleneck is not the NFX interface - reads and writes through the interface take place at the same speed, the bottleneck is the speed of writing the file by CP/M.

 CPM that is slow at writing for 2 reasons :

  •  De-blocking CP/M's 128 byte sectors onto the CFX's 512 byte sectors is a lot of work. When writing a file, CP/M has to go looking for blocks to allocate, when reading they're in the FCB ready. For every 128 bytes written, the CFX code has to read 512 bytes into the buffer, update 128 bytes and write 512 bytes back. If the next CPM sector written is in the same CF sector the read step can be skipped. So the best possible speed for 4 consecutive sectors needs 1 CF sector read and 4 written, Which is 2560 bytes transferred 5 times as long as reading, Worst case would be 8 to 1 when writing 1 CPM sector that's not already in the buffer, which needs 1024 bytes transferred to write 128 bytes.  
  • The free block search time is variable, but takes longer the further it has to go into the disc map to find an unused block. So scanning a typical CFX  B drive of a 1/2 full 8 meg partition cloned from ReMemorizer isn't going to help!

Because of these limitations, it will not be possible to increase the speed when savings files to the MTX over the network, however, even with this limitation, I think that it us a really useful enhancement to an MTX.

 

 

 

mailto: Webmaster

 Terms & Conditions