search

durgadas311 / cpnet-z80

27 stars 6 forks source link

Adapting inettools-z80 (ifconfig) for other platforms (Heathkit) #8

Open durgadas311 opened 4 years ago

durgadas311 commented 4 years ago

The WIZCFG.COM utility was a simplistic, but effective, method of configuring CP/NET on WizNET W5500-based adapters. IFCONFIG is better in that it supports DHCP, however it needs some extensions in order to support features of the Heathkit platform.

1) Heathkit maintains W5500 settings in NVRAM by default, so a Heathkit versions needs to support both updating settings in NVRAM as well as W5500, defaulting to NVRAM. 2) Heathkit also supports "static drive mappings" (and LST: mapping) stored in NVRAM, to avoid having to use NETWORK after every startup of CP/NET. 3) It would also be nice to have the option of using a static IP address, instead of DHCP.

durgadas311 commented 4 years ago

One issue with using DHCP on Heathkit (NVRAM) systems is that the IP address is stored in NVRAM, and configured from there every time CP/NET is started. It may not be practical to try and build-in DHCP to the CP/NET startup routine. In addition, the default action to configure into NVRAM does not otherwise require the W5500 to even be installed, but with DHCP it must be installed and operational, and have a MAC address.

jayacotton commented 4 years ago

MAC address. There is an issue. The MAC address is supplied on a small slip of paper. It is not a burned in feature. On rc2014 I have a file 'mac.cfg' that captures the MAC address.

Maybe wizcfg could have an option to write the info to a file/nvram (as needed) and the tools could pick up the info when they startup. I'v been flopping around for some time now, trying to come up with a good way to deal with semi perminant storage.

For DHCP, I think we use it during wizcfg and then we have an IP stored that can be used by all the tools and avoid retracing the same ground in each tool. We are writing a 3 in the magic register, we could use that as an indicator that the part was configured since last power up, the tools could then refer to 'wiz.cfg' file for any configuration info.

Most modern computer have a config switch (s/w) that enables/disables DHCP. We could implement the old /etc/hosts file idea, and make that the other option.

How large is the NVRAM on the Heath ? I am thinking of a get/store abstraction layer to get around the decision of how to store info.

I think that once the user gets all the required info into storage, there is not real need to run the app again, unless there is a system change.

durgadas311 commented 4 years ago

The Heathkit platforms, using that version of WIZCFG, use the first 512 bytes of the NVRAM. The first 32 bytes store a sparse image of the W5500 "Common Register Block". The next 8 blocks of 32 bytes (256 bytes total) hold sparse images of each Socket Register Block (sockets 0-7). In the socket blocks, the Sn_KPALVTR value (W5500 offset 47) is relocated to offset 29 (reserved - unused). Following these 9 blocks of 32 bytes is an image of the CP/NET configuration table, used to pre-set networked devices. The last 4 bytes of the 512-byte block stores a 32-bit checksum (simple sum of 508 bytes), little-endian.

The Heathkit versions of CPNETLDR and NDOS3 non-resident startup code will read the NVRAM and initialize everything from that, prior to starting NDOS.

The actual NVRAM chip used is the Microchip 25LC512, which has a capacity of 64K bytes.

durgadas311 commented 4 years ago

I'm not all that familiar with DHCP, but on "normal" systems the DHCP client will periodically renew the DHCP lease. I know most modern home "routers" allow one to permanently assign IP addresses to MAC addresses, although I'm not sure if that still requires renewal. Is there some part of the DHCP protocol that allows for a "permanent lease"? I'm just wondering if a router could expire the lease and assign the IP address to some other device, causing a conflict if the W5500 insisted on using the IP address without a DHCP lease.

Obviously, in all cases the W5500 must be assigned a valid (unique) MAC address, although it could be designated a "locally unique" MAC address in which case in need not be globally (world/universe) unique. One scheme is to take old (ancient, retired) NICs and re-use their (globally unique) MAC address. But one could also set the proper bits in a locally-generated MAC address and be fine - as long as the W5500 is hidden behind a firewall/router from the Internet (which is normally the case).