WANTED: Translator from German
Mr. Emmanuel Roche, France
http://www.kc85.susowa.homeftp.net/
On the home page, search for "KCNET 1.2". Under the "1.2", there is a link
(in blue) called "KCNET". Click on this link (the other, "Projekte" goes
somewhere else).
You now arrive on a page which lists 7 files.
I need to know what they say. Maybe it is not necessary to translate
everything and just the last two files ("KCNET TCP/IP-Stack" and "KCNET
1.2") would be enough?
I dumped the CPMNET program: all the messages are in German, but the error
messages are in English...
Among other things, I would like to know what they use at the hardware
level, if the program is portable to others CP/M systems, and if the source
code if available (the file is 24KB), and what it can do, exactly (surely,
it is not a Web browser?).
(Many years ago, I wrote that the KC-club was the only place where active
CP/M development was taking place, after they published a message asking if
someone wanted one of their GIDE cards. What a pity that they don't have an
English version of their Web site! Everything is in German... And don't let
us know what they are doing, isolated in their corner. Too bad that I don't
know German, else I would have translated their stuff for free.)
Yours Sincerely,
Mr. Emmanuel Roche, France
Katzy
Mr. Emmanuel Roche, France wrote in message
<48897099$0$946$ba4a...@news.orange.fr>...
>You now arrive on a page which lists 7 files.
>
>I need to know what they say. Maybe it is not necessary to translate
>everything and just the last two files ("KCNET TCP/IP-Stack" and "KCNET
>1.2") would be enough?
>
>I dumped the CPMNET program: all the messages are in German, but the error
>messages are in English...
>
>Among other things, I would like to know what they use at the hardware
>level, if the program is portable to others CP/M systems, and if the source
>code if available (the file is 24KB), and what it can do, exactly (surely,
>it is not a Web browser?).
Greetz, Katzy.
Mr. Emmanuel Roche, France
Written of Ralf Kästner
Dienstag, 15. Juli 2008
The optimization of the hard and software of the KCNET interface is final
and now also for all users of a CP/M 2.x of system with Z80 CPU problem-free
after usable.
The last 10 per cent last usually longest. That is with the KCNET project
unfortunately also not differently. However, today is it again once a large
actualization to give. Meanwhile from the usefulness, as to the KC-meeting
2008 demonstrates, a usability
for all CP/M 2.x became user with a Z80 system.
FIRMWARE 1.2
------------
Here any longer in principle much was not to be done, since actually all
functioned very reliably. For speed reasons however the sequence of the
minutes functions was changed over in such a way that at most used and
time-critical instructions against the beginning and the fewer frequently
needed functions against the end were placed.
The two functions for the call of hard and/or software-Version of the
interface were rewritten by ASCII on binary output, since for version
control from the Z80 software is handier.
In order always necessary software of components of network programs
determined convert more elegantly and the TCPIP driver in the Z80 system
Rome-able to hold to be able, was added further 5 minutes functions, which
are converted internally by the firmware and nothing with the WIZnet TCPIP
stack to do to have.
The interface offers now for the Z80 system a time service in form to
infinitely running milliseconds of a counter from 0 to 59,999. Over the
computation of the difference
of 2 counts one is like that in the position to measure both small time
intervals within the ms range and to seize large distances for Timeouts etc.
of purposes and above all
hardware-independently of the host system.
Further can be stored and read backwards now in the interface up to 8 IP
addresses. Up to now only one number for the file of the DNS server inquired
by DHCP is assigned in the network, which becomes 7 further available places
in the course of the
time to still define surely, what also is dependent on converted network
minutes and/or one determines by their requirements.
Many TCP and/or UDP minutes develops connections in the network outgoing
over arbitrary haven numbers. But the range is intended from 49152 to 65535.
A condition is however that the selected coincidental haven number differs
from 2 or more connections,
thus the allocation of detailed answer packages in the TCPIP stack is clear.
But there is now also an interface function, which returns the next haven
number starting from 49152 ascending with each call and so that for the
adherence to the condition mentioned provides, at least for 16383 of calls,
which more might be than sufficient.
With the last new function the internal counter for the arisen command
errors can be selected with the call of the firmware instructions. That is
more for the programmer von Interesse. Particularly, if one writes new
programs, one can control thereby the correct use of the KCNET commands.
Usually should be always read backwards there 0, otherwise is not correct
somewhat yet with the new program!
HARDWARE 1.2
------------
In the course of the optimization already longer oszillografische control of
PIO communication with the ATmega was planned. I expected there no problems
however at least once look at belonged simply to it. I had correct interest
however at a thing - as fast
the PIO fetches the bytes with a command from the interface, thus stands and
falls the data transmission rate of network communication, speaks is the
thinnest place of the whole chain there.
As expects, existed with the handshake of the byte transmission problems,
the left picture, the right receiver does not show the transmitter.
Handshake is completed over 2 signals, above is the ready exit of the PIO
channel and down /STROBE-Eingang. Both of
the expiration and the signal lengths that is completed everything according
to plan.
The next picture shows the complete operational sequence of the command "
Vintage left Status" , there 1 command byte is sent and 1 answer byte is
fetched.
The place, which me now to most interested, shows the following picture.
Here one can see the temporal operational sequence when fetching several
bytes under CP/M and concomitantly the reason, why I wanted to absolutely
look at that.
First realization was, which is ATmega fast enough, immediately after RDY
goes on H, comes /STROBE-Impuls for the writing of the next byte into the
receive register of the PIO. Thus firmware-laterally no more optimization
need might exist.
Secondly the PIO is also not the problem, it makes exactly what is to run
off according to data sheet. After a byte in the receive register landed,
RDY goes on L and could be fetched and processed after acceptance and
processing of the receipt interrupt, which
signals the received byte to the main program, from this.
And the reason for the nevertheless quite leisurely function of the KC85 is
not exactly there under CP/M. is actually that anything new however a
distance of approx. 260 µs between two receipt bytes offers nevertheless
still substantial optimization potential, which
has to do only by a further improvement of the interface driver and all this
which thereby, be exhausted can.
A first measure was the extension of the past interface, so that PIO
communication on the Z80 side can be completed also in the Polling. One can
save then time-moderately the entire mechanism of the interrupt
acceptance, - processing and - to completion,
whereby however in terms of hardware it is to be ensured that the condition
of the two RDY exits of the PIO can be queried by software.
Exactly that still changed in the connection diagram, ARDY goes directly on
PIOB0 and BRDY goes inverted on PIOB7, PIOB1 to PIOB6 go at mass and always
are thereby during inputs of channel B 0. The channel B was not used by
software so far already driven in the bit enterprise however.
The changed connection diagram of the version 1.2 is to be found in the
Downloadbereich.
CP/M DRIVER KC85
----------------
A thing planned anyway was particularly higher for the KC85/4 and the
extension of the CP/M drivers. Conditions for it are a KC85/4 upward, ZAS4
at least in the version 1.3 and appropriately the load program for DRV
drivers DRIVER.COM.
First the past ouple driver, which uses the PIO in the INT enterprise, was
not adapted to the changed hardware version, the first variant functioned
thereby any longer!
Subsequently, a second variant of the ouple driver was provided, which uses
the PIO in the POLLING. That has besides still the advantage in relation to
the INT version that an inadvertent Interrrupt of the initialized PIO in the
basic equipment does not lead no more after change into the CAOS mode of
operation to a crash of the D001, if the driver code is no longer present.
This driver should be used for this reason immediately according
to standard, if one does not use the DRV variant and/or can not
use (KC85/3).
The use of the ouple interface of the KC85 requires a considerable
expenditure on the KC85 system for byte transport to/of the KCNET interface.
For everyone byte which can be transported is necessary a BIOS CALL
readers/Puncher of channel, the which releases e.g. procedures following
with sending:
- CP/M program hands 1 byte at BIOS to function over 6
- BIOS function puts the byte down in the ouple RAM
- BIOS function demands the expenditure of this byte in the D001 with ZAS at
- ZAS recognizes the requirement and reads the byte from the ouple RAM
- ZAS calls the ouple driver in the D001 and
- hands the byte over of the ouple drivers
- writes the byte into the output register of the PIO
- the KCNET interface fetches the byte
- the ouple driver returns to CWS
- ZAS acknowledges the expenditure byte to the D004
- BIOS function recognizes the acknowledgement
- BIOS function returns to the CP/M program
- the next byte can be sent of the CP/M program
The receiving runs off similarly and this whole chain for each individual
byte to went through, which requires enormous amounts at time! Already with
the MTOOLS/WTOOLS project Mario Leubner at CWS filed something, so that it
under certain circumstances somewhat leaves itself faster will however in
principle this long chain, which is due to the hardware of the KC85, not to
naturally go around.
The only promising variant consists of reducing the number of the calls
and/or transmissions by handing over and/or from the D001 reading bytes at
one time per call as much as possible to the D001. One must take the way by
the ouple RAM nevertheless however the whole expenditure for acknowledgement
and call of the subroutines
is void starting from the second transferred byte completely for each still
following.
Exactly that was then the next optimization measure and is meanwhile in form
of the new driver KCNET.DRV converted. The driver works also not more on the
lowest byte transportation level, but already on the level of KCNET minutes.
The CP/M program can call thus directly a KCNET function in the D001 and
gets immediately the answer data in
the ouple RAM supplied, which likewise saves a quantity of time. The most
important innovation lies however in the implementation of a block transfer
for up to 255 bytes per read/recording procedure in the ouple RAM and that
is very clearly to be felt, sees last
section.
SOCKET INTERFACE for WIZnet TCPIP STACK II with W3150A+ or W5100
----------------------------------------------------------------
The SOCKET interface for network often commodity, announced in the last
article, was almost complete in March to the KC-meeting and by CPMNET 1,3
was already intensively used.
There were problems however still with the RECEIVE FROM function, where me
the last details of the TCPIP stack were not completely clear. Here
unfortunately neither the data sheet nor the WIZnet helped me " C" - Drivers
substantially further. In the meantime
in addition, this hurdle is taken and finally works all functions as
desired, even if one receives for example UDP packages with a length more
largely 1472 byte. That cannot process the stack and came before the sock
temp catch now the package of the driver
correctly rejected however is in disorder, acknowledged, so that one can
continue using the Socket completely normally.
With the today's actualization one can now use this whole history. In the
Downloadbereich (source texts, CP/M assembler) there are the new CPMNETQ.PMA
in the version 1.4. In this archives is the file CPMNETW2.INC, which
contains the complete TCPIP driver,
which one can using and into own programs merge in the same way as
CPMNET.MAC.
CPMNETW2.INC makes the access available to the TCPIP stack as subroutine
collection and encases the underlying driver functions of the KCNET
interface. That makes a use substantially simpler and safer - the danger of
a false programming of the KCNET interface driver is almost excluded,
naturally only, if one keeps the appropriate parameters.
For comfortable programming of network often commodity the following 18
functions are to source texts at the disposal, which are accordingly
commentated in the file, the use can also easy to that of CPMNET.MAC be
inferred. For the moment to it no detailed documentation is planned, since I
want only times to wait for, whether and how a Nachnutzung develops me am
enough as developers the comments in the source text: -):
Init and Status: SOCKET, BIND, SELECT
Connection establishment: LISTS, ACCEPT, CONNECT
Data communication: SEND, RECEIVE, SEND TONS, OF RECEIVE FROM
Connection clearing: SHUTDOWN, CLOSE
Administration: GET PEER DATA, GET OF LOCAL DATA
Conversion: HTONS, NTOHS, HTONL, NTOHL
In the Socket interface fundamentally nothing more will change, up to the
addition of missing functions and smaller auxiliary functions, which one
anyway always needs. Since the driver is translated however with the
program, one can in-maintain changes
by a re-translation relatively fast. As said no substantial changes are
planned more from my side, since meanwhile everything is tested and was
already accomplished with the development of CPMNET.COM each quantity
optimizations and adjustments.
CPMNET 1.4
----------
With the many changes and additions at firmware, drivers and functions there
was each quantity to naturally then do right at the top in the CP/M program
also.
CPMNET.COM is present now in the version 1.4 and conditions reached, which
on arbitrary CP/M 2,2 compatible systems with Z80 CCU permits a universal
Nachnutzung. All functionalities of the KCNET interface are made accessible,
one can with various parameters of the WIZnet TCPIP stack play and for the
employment in the network bring along it equal the absolutely necessary
things, so that one can loose-put
immediately.
A complicated affair was the change of the source texts and their modularity
for the universal Nachnutzung. The KC85 specific things is now all in the
file CPMNETKC.INC, one can let which replace simply by the variant
CPMNET.INC.
Which must be made exact, I will write in a separate article. Then the
program should function after minimum adjustments and renewed translation
immediately with other CP/M 2.x compatible systems, which direct access to
the Z80-PIO and thus the KCNET
interface have.
The TCPIP driver with SOCKET interface is likewise in its own file
CPMNETW2.INC and perfectly hardware independent concerning the KCNET of
interface driver.
The actual program was provided now also with various querying and test
routines, so that necessary system conditions are examined and with
nonexistence a message take place and the program start are broken off. On
the KC85 system one can work
stress-free both with KCNET.KOP and KCNET.DRV, those DRV variant is
preferred, if both drivers are loaded.
In the course of the revision to the version CPMNET.COM a further menu got
1.4 spendiert, so that one can call functions or whole programs now suitably
to the hard and software logic on 3 levels, I begins times from downside.
"INTERFACE-MENU"
Here in the head the versions are indicated to the firmware and hardware and
the network status.
With the figure keys one knows the indicated functions of the KCNET of
minutes *zu Fuss" test, a complete list is in the file " KCNET V1.2 PRG.pdf"
in the Downloadbereich.
If one wants to release here sinvolle actions, one should argue with the
data sheet of the WIZnet TCPIP stack, which one can download oneself of the
website http://www.wiznet.co.kr.
Either one looks for " W3150A+ Datasheet" or looks within the range LIBRARY
> TO DOWNLOAD CENTERS themselves after.
Addressmoderately the stack in the KCNET interface from 8000H to FFFFH can
be attained, to all data in the data sheet is thus an offset from 8000H to
be added, it arises the following start addresses for the KCNET:
COMMON REGISTERS 8000 H
SOCKET REGISTERS 8400 H
TX MEMORY C000 H
RX MEMORY E000 H
"TCPIP-STACK MENU"
The current IP address and Subnetzmaske of the interface are indicated above
and whether detailed PING echo requirements is answered or not.
With the help of this menu various parameters of the WIZnet TCPIP stack can
be indicated or changed. The function " C" the current TCPIP configuration
of the stack gives similarly the DOS command " IPCONFIG" out. With " R" the
complete stack
is put back, whereby one can receive or delete let an existing network
configuration. The commands 1-7 (4 only readably) set the appropriate
registers of the stack according to data sheet with the values which can be
entered. The function 8 indicates
the current conditions of the Sockets.
A manual configuration of the network parameters is likewise made in this
menu and enclosure at least the input of valid parameters for the IP address
(1) and Subnetzmaske (2). Subsequently, the CP/M computer in the network
should answer to PING commands.
"NETWORK MENU"
Here it slowly interesting for the user and this menu is then indicated when
starting of CPMNET.COM also always.
Within the upper range one sees its own IP address and the current haven for
communication on UDP and/or TCP level with the appropriate test functions
(3, 4, 5). Behind PEER that stands again, which is the data for the other
computer with
which one to communicate wants.
With the functions 1 and 2 one can change these values, so that it fits for
the own network. In order to be able to communicate with a Windows PC, one
can procure oneself from http://www.hw-group.com from the range SOFTWARE the
program
HERCULES.EXE. After the start of the program one selects the appropriate
side with the riders right at the top, registers IP address and haven of the
CP/M of computer and can then as with a terminal program text message send
away and receive:
CPMNET (CP/M) HERCULES (Windows)
------------- ------------------
3 - TCP SERVER SOCKET TCP Client
4 - TCP CLIENT SOCKET TCP Server
5 - UDP SOCKET UDP
With the first two variants always only the server is to be started and
afterwards with the Client be connected, whereby always on both sides the
haven numbers must agree. UDP works connectingless, can communicate thus
reciprocally immediately in addition, only with same haven numbers!
The function 6 works on IP level and does not indicate, if another computer
the CP/M computer anpingt, answered however this messages not, so that one
always gets Timeouts announced on the pingenden computer.
With the function 7 on the MAC level with the CP/M computer arriving and
Ethernet of packages intended for it is indicated, that has to far no use
separates serves only for test purposes.
DHCP, PING and TFTP
-------------------
That should not originally at all also into the KCNET test routine inside
however after at the beginning of the yearly the programming bases for the
first correct network application was put, could it actually loose-goes with
the conversion of various RFC' s. A program for everything is also only
times handier in the test phase. If the interface should be after-used
times, one can outsource these minutes later problem-free into its own
program each and merge then also in batch files or the like.
The home network today tied up over one rout usually to the Internet,
whatever inserted often a SWITCH for the connection of several network
participants. Typical representatives are " the widespread; FRITZ! Box" -
EN, which can complete additionally the telephone service by VoIP also.
The firmware of such Routers actually always integrated a so-called DHCP
server, which can distribute automatically the IP addresses for the network
administrative and free IP
addresses and other parameters to inquiring participants for the
administration of the attached network participants, so that one does not
have to worry about the whole
configuration at the computer no more.
But computer-laterally a DHCP Client is needed, which can procure itself its
IP address and different network parameters of the DHCP server of the
Routers and exactly that was the first application of networks in the
CPMNET, since the händische configuration of the KCNET made me nervous at
that time somewhat.
Meanwhile I could test the Client also with several quite different DHCP
servers, e.g. various " FRITZ! Box" Models of AVM, which " Speedport" the
Telekom in Ballenstedt, the software DHCP server for the Desktop versions of
Windows on
http://ruttkamp.gmxhome.de and the DHCP server of http://www.isc.org, which
runs on my own network server and which IP' s administers. The following
picture shows the successful configuration of the KCNET in my network by
DHCP:
"DHCP CLIENT 1.0"
If not the most important tool is at all, the mandatory PING CLIENT for the
examination of other network participants. That was built in March and
revised in June again and improved, for the moment however still without DNS
Namensauflösung. That is missing still with the Socket functions however its
course-thought purpose fulfills it also in the CPMNET:
"PING CLIENT 1.0"
One knows naturally also Internet IP addresses behind routs to anpingen,
however only, if one knows and enters the IP address of the server
accordingly. The gateway address of
the Routers is determined by the DHCP Client and the WIZnet stack configures
accordingly automatically, thus genuine Plug and Play with the KCNET in the
network.
In order to draw a practical use from the whole trouble, still another
program for the data communication should be finally inserted, here
presented itself as entrance project at first sight uncomplicated TFTP
minutes.
After that functioned in principle, to control tries the W3150A+ with its 4
Sockets times a little. After the start of TFTP a Socket is always reserved
for the server, which constantly runs and waits on detailed requirements of
network participants. The other 3 Sockets is used dynamically, in order to
transfer files from computer to computer, which can run off also
asynchronously, parallel and in arbitrary directions.
The CP/M computer can be used thus by TFTP simultaneously in the
Client/server enterprise with file transfers simultaneous up to 3 in all
directions. That has then however already correctly work made, until all
functioned, all events, current procedures and not-current procedures
(Timeouts) must in ONE in the end quite complicates looking loop
to be processed.
The following picture shows the TFTP SERVER & One sees the current
transmissions to CLIENT 1,0 in action, within the lower range of the
Screenshots, from 192.168.0.20
RUMPI.KCC to the KC85 is sent, 192.168.0.10 fetches themselves UNIVERSE
KC.SSS from the KC85 and the KC85 fetches itself BOULDER.KCC from
192.168.0.2:
"TFTP SERVER & CLIENT 1.0"
As transfer partner up to now only the PC is possible. For Windows one knows
the program " PumpKIN" by http://www.klever.net/ use or the Freeware program
"3CDaemon" by http://www.3com.com/ - there as search word " 3CDaemon" enter,
which select first hit and which download file 3cdv2r10.zip.
I use usually " PumpKIN" , there it also by Drag' n' Drop to be served knows
and many individual attitudes permitted, in the following picture fetches
themselves the CP/M Client
a straight file from the Windows server.
'PumpKIN"
With Windows XP and Linux one can use also the console programs of the
Clients, simply times TFTP in the DOS window and/or console enter, files is
in principle in the binary Oktett mode to/from the CP/M computer to be
transferred! Under Linux naturally the appropriate user rights and haven
releases are in the Firewall to adjust correctly - to me is not to be
written up to now also yet successfully from the KC on the Suse
Linuxcomputer, in principle should that go, because reading functions also!
PRACTICE TEST KCNET 1.2
-----------------------
Around the whole optimizations something to clarify I accomplished some
tests in July now still. But one needs the WIZnet own Windows program AX1,
which one finds Internet address there in the Downloadbereich (for AX1
look), sees above.
Since the way of the data is complicated of/to the interface of the KCNET
with the KC85 under CP/M something, it was not at all simple so to achieve a
reproducible measurement of transmission rate. If possible no system
attitudes or other factors the comparability of the results should disturb
and also for everyone be comprehensible.
Therefore the AX1 presents itself program. It sends data to the KC85, which
receives it with the KCNET interface, where they take the way over PIO,
driver in the D001, CWS, ouple RAM, CPMNET, which them put down in the TPA
and send back invariably from the TPA reverse way to the PC program, which
verifies and indicates the correct receipt.
If one tacitly assumes receipt and transmission work symetrisch, one can
divide the determined total time of the transmission by 2 and receives
thereby a measure for transmission rate of the interface. Whether absolutely
in Byte/s accurately is correct, is also only times secondary - the increase
of the speed is to be determined in any case in this way exactly. Since a
RAM takes place to RAM transfer, also no storage media brake the
transmission out, particularly on the CP/M side exist this danger.
For the test in the PC the same was always loaded file and over a
manufactured TCP connection between PC (Client) and KC (server in the
transmission with information feedback) transfer. The length of the file
(51164 byte) is divided by the time difference between start and end of the
transmission and the result is multiplied by 2, which finally results in the
transmission rate of the interface in byte per second. In the following
table the different test results are to be seen:
Optimization of transmission rate on KC85
Test data file: TEAC.PDF with 51164 byte
Test Driver Handshake Total time Byte per s Remarks
---- ------ --------- ---------- ---------- -------
1 KOP Interrupt 52,85s 1936 Bytetransfer
2 KOP Polling 46,55s 2198 Bytetransfer
3 DRV Polling 14,33s 7141 Blocktransfer direkt, BS
SCROLL-Mode
4 DRV Polling 13,95s 7335 Blocktransfer überlappend,
BS SCROLL Mode
5 DRV Polling 9,51s 10760 Blocktransfer überlappend,
BS PAGE-Mode
Most important realization - the block-by-block data communication of up to
255 byte at one time by the ouple RAM with the DRV driver becomes very
clearly apparent in relation to the variant byte by byte on use of the KOP
driver - approx. 500% increase!
In addition, with the KOP driver one comes still on an acceptable
transmission rate during the data communication, to the meeting with the
KCNET version 1.1 still lay with approx. 1000 Byte/s, even if it were to
more there because of the software timer of the CPMNET, which braked the
program and not at the interface.
Perhaps still to understand, block transfer directly means that in the D001
directly a I/O (PIO) takes place to I/O (ouple RAM) transfer. With the block
transfer overlapping the PIO data are put down in the RAM of the D001 and
from there with only one instruction in/out/the ouple RAM written/read,
whereby the D001 already reads the next block in, while the D004 above
writes and is turned around, thus like small cache formed the data
into the TPA.
BS is called screen and plays also still another role with the KC85, in the
transmission with information feedback per TCP package at the screen a
message is always spent and if the last line were reached, the whole screen
in the SCROLL mode must be rolled up,
that lasts for a very long time, since it must be accomplished also by CWS
in the D001, in which time can then also no KCNET data will transfer.
KC85 is natural far from theoretically possible 1 MB/s WIZnet chips to AVR
CONTROLLER far away, which is due to the PIO binding however we needs no
more as the 2 kB/s, there lies approximately the limit, with which CP/M can
write the data
on the non removable disk, therefore does not have also the users of the KOP
driver not to be annoyed (KC85/3), from data medium to data medium goes it
with DRV also not faster.
All theory is grey, I wants which to see - one can in the Downloadbereich. I
noted to the illustration with test 1 and 5 the Windows Desktop and as video
into the Downloadbereich placed, to find under documentation > Documents. At
the bottom left hand corner in the video a real-time clock runs along, there
can one the transmission times exactly read off:
Test 1 : KCNET12 TCP-ECHOSERVER KOP INT.MPG
Test 5 : KCNET12 TCP-ECHOSERVER DRV.MPG
RESULT and VIEW
---------------
Thus my KC85/5 under CP/M is now already full member of my TCPIP
Heimnetzwerkes, the network configuration effected automatic by DHCP and I
can with arbitrary network participants data exchange, if she " TFTP;
sprechen". Practically tried out one did not function so far with Windows,
Linux and BSD Unix and it - yet particularly comfortably however very
stably.
With the version 1.2 I would be now also ready to set the firmware for the
Nachnutzung for the order as to the KC-meeting was discussed, in addition it
also still another article will give extra. At the interface hardware I
become no more changes distinguished and at the firmware in the near future
also not, which leaves itself with necessity to program again.
For the KC85/x owner is a KC-module in work, all other prospective customers
would have for their system thoughts to make itself, how they can bring a
PIO into their hardware or use an existing PIO. Since a Z80 standard circuit
is used as interface, that is actually no problem. In the source texts of
the firmware an adjustment is
inserted, that in the case of the translation is upward already considered
automatically accordingly to other clock frequencies of the CPU/PIO of the
host computer starting from 500 kHz.
I will continue to work in next time on the software and perhaps still
missing functions, as e.g. supplement the DNS Client. Also for the CAOS mode
of operation of the KC85 still software is to be provided. That depends also
everything little of it, how the interest in a Nachnutzung develops. I
already reached my minimum goals with my interface Unikat.
Which is also still missing, is the test of the newer Netzwerkmodules of
WIZnet, where the W5100 is used. With the WIZ811MJ there is now even a
amateur-friendly variant with pin rows in the 2.54 mm rasters, so that it
can be taken also on a Lochrasterplatte problem-free in enterprise. In the
theory the module should function after changing
the appropriate Jumpers in the connection diagram immediately.
Last actualization (Wednesday, 16 July 2008)
EOF
Mr. Emmanuel Roche, France
Written of Ralf Kästner
The KC85 goes to ON-LINE ONES.
------------------------------
There is to be people, which it not to expect at all to be able to finally
have its good old KC85 at the network and/or Internet. I surely also belong
to, otherwise I would not be occupied already 4 months continuously with it.
But it becomes slowly light at the end of the tunnel!
Since the last interim report already again some time passed. At the
beginning of January was concentrated continued the work on the project very
intensively and.
After the start-up of the interface next the implementation of suitable
software for the access on the WIZnet was TCPIP stack at the row. As
collecting main the C-source texts of WIZnet were available in form of a
driver for the AVR GCC compiler.
Everything was programmed in Z80 assembler for the M80. The software places
the accesses as subroutine collection aquivalent to the original C-functions
ready and encases the underlying driver functions of the KCNET interface.
That makes its use substantially simpler and safer - the danger of a false
programming of the KCNET interface driver is almost excluded, naturally
only, if one keeps the appropriate parameters.
Parallel to it first the CP/M program was gradually extended CPMNET.COM, in
order to be able to test developing functionalities. To 06.01.2008 was it
then finally so far:
My KC85/5 communicates with the help of the KCNET interface under CP/M over
TCPIP and Ethernet with a Windows or a Linux PC.
That was not at all so problematic a mad feeling and, as I had actually
expected. The WIZnet chip functioned " einfach" and can be taken at a really
small expenditure fast and uncomplicatedly in enterprise.
Afterwards only once Herumspielen was announced and I has tried with all
possible programs to manufacture minutes and various servers in the network
and Internet contact. Step by step it went then better and better forward
and I was at the end of this experimentation phase in the situation to
address and use all layers of the TCPIP stack.
CPMNET.COM got a second menu page, which makes some special programs
available to be able in order would drive through on these levels
corresponding tests:
- the KC85 as TCP servers
- the KC85 as TCP Client
- the KC85 as UDP Client/servers
- Announcement of detailed ICMP packages on the KC85 (Ping from the outside)
- Announcement of Ethernet packages on the KC85 (network Sniffer)
With the help of the first 3 programs one can send and receive then already
times text messages over the line - as it the usual Chat programs strictly
speaking to also only do.
For somewhat longer tests the KC leaves itself also into the transmission
with information feedback scolded and represents then a TCP or a UDP echo
server there. That is, it sends back all received data invariably to the
transmitter, which it verifies then. Thus one has to check a comfortable
possibility the entire transmission chain in continuous operation for
accuracy.
And which I am to say - it functions simply marvelously. The KC85 sets up
here no speed records, that was naturally also not my primary goal. The
technical conversion of a clean Ethernet binding and the integration are
crucial to my TCPIP Heimnetzwerk, additionally are attached still one
thereby besides also to the Internet for me.
And there there are some things to still settle, although the most difficult
sections behind me lie. For the moment it looks in such a way that for the
subroutines specified above still another superordinate logical abstraction
level is developed. On other computers this interface than Socket interface
is well-known, which standardizes and makes programming very clear of
network often commodity for TCPIP.
If one wants to access in its program network/Internet, one procures
technically seen a channel (Socket), opens it with desired minutes and
parameters and can begin immediately with sending and receiving. The 4 most
important functions of the data communication - SEND/to RECEIVE and/or SEND
TONS/RECEIVE FROM - are already settled and straight in the test phase,
which becomes administrative and auxiliary functions shortly to follow.
The following source text excerpt shows for example the transmission routine
of the initialized TCP Sockets, which sends on the console entered the data
(INCON) on the journey:
; Input & Send TCP-DATA
SEDATA: CALL INCON ;PA: HL/BC - HAdresse/SIZE
LD A,(SOCKET)
SWDATA: PUSH BC ;SIZE TO SEND
CALL SEND ;Send TCP-Data
POP DE
RET C ;Fehler
EX DE,HL
SBC HL,BC
EX DE,HL
LD B,D
LD C,E ;SIZE = SIZE - SENT
JR NZ,SWDATA
RET
The receiver lets itself be programmed just as simply. In the following the
excerpt of the TCP Server/Client with the TCP receipt, the echo mode sends
everything back equivalent again, otherwise all data are spent on the
screen:
; Receive TCP-Data to CON or ECHO
REDATA: LD A,(SOCKET)
LD HL,LINEBF
LD BC,MAXSEG ;Size max.!
CALL RECV ;Recv TCP-Data (RecvSIZE BC)
RET C ;no Data
LD D,A
LD A,(SECHO)
OR A
LD A,D
JR Z,REDAT1
; ECHO MODE
LD HL,LINEBF
CALL SEND ;Send TCP-Data (BC)
RET
; CON MODE
REDAT1: LD DE,TCPMX4 ;received
CALL ZKOUT
REDAT2: LD HL,LINEBF
PUSH AF
REDAT3: LD A,(HL)
CALL COUT## ;to CON (BIOS)
INC HL
DEC BC
LD A,B
OR C
JR NZ,REDAT3
POP AF
LD HL,LINEBF
LD BC,MAXSEG ;Size max.!
CALL RECV ;Recv TCP-Data (RecvSIZE BC)
JR NC,REDAT2 ;get all Data
CALL NEWLN
RET
With this Socket interface the KC85 is then able, which is both fundamental
transportation minutes TCP and/or UDP in a simple and standardised way to
use and my preparing work terminated. On this interface then all network
programs can put and at more or less expenditure those on perhaps rather
admitted applications to realize also with the KC85 under CAOS or CP/M:
- Internetbrowser by HTTP
- File exchange with TFTP or ftp
- Registration on and remote control of other computers with telnet
- E-Mail with SMTP
- Interaction (new server) with NNTP
- Transformation of Internet IP addresses in Domainnamen and in reverse with
DNS
- Network services with CIFS/SMB
- "The sky the limit..."
One could continue the list nearly at will, it gives an almost
difficult-to-understand number of minutes, services and applications for
networks which are based on TCPIP (several 100), which are in use and again
and again new are added.
By the choice of a TCPIP stack in hardware for the project first of all a
stable enterprise of the network interface should be problem-free
convertible possible and secondly some above mentioned applications. The
reason for it is that by the compact programming of the TCPIP
Treibers/Socket interface in assembler the 64 KB RAM of the Z80 system the
available are hardly loaded.
The complete interface software with Socket interfaces needs approx. 1.5 KB!
Memory and CPMNET 1,3 with the today's function range approx. 9 KB, whereby
the driver with 1,5 KB and a buffer are included of 1,5 KB for the echo
server enterprise there. Thus all possibilities should stand openly of
programming network often commodity and of merging the driver there simply
with, without having to accept a considerable TPA load under CP/M.
For me then referring also point 7 of the timetable would be checked off to
the last article. With the successful start-up of the TCP/IP stack thereby
the Ethernet interface with the KC85 is no more dream, but reality and TCPIP
give it as addition with an appropriate interface obendrauf.
In the following then as usual still two Screenshots of the current
software - CPMNET 1,3, a publication of the sources will give it to a later
time. For the moment existed only the prototype of the KCNET and the
programming of the TCPIP interface are not yet completely final, so that the
putting on programs change nearly daily.
"CP/M-NET 1.3"
Menu 1 for the test of the KCNET interface
"(IP:Port)"
Menu 2 for the test of the TCPIP stack
As far as to the present conditions, in next time it will give probably only
times no further Arikel, since I mean work to the end to bring and
afterwards still another 2008 in April would like to try few ideas out for
the KC-Clubtreffen. There one can look at oneself all Live and in color,
registration information, place and time can one on the website of the
KC-club experience.
Last actualization (Wednesday, 30 April 2008)
Mr. Emmanuel Roche, France
CP/M-Forum » Softwareprojekte » IP Stack im CP/M, wozu? » Threadansicht
10 September 2007, 21:10 "FanDjango" wrote:
Question to all:
We accept a Ethernet interface nevertheless times fun for the sake of, one
would have at a Z80 CP/M computer coincidentally and even in Z80 assembler a
stack for the order.
One would know which applications then relatively simply " schreiben" , over
with it to work?
1. TFTP?
2. a small part of ftp?
These two would be nevertheless very practical.
3. CIN, CSTS and COUT raus put servers on telnet?
That is called telnet from outside on the CP/M CONSOLE
4. Drive assemblies to merge probably far away each possibility might be
And then they left me...
HTTP to serven is not that which me primarily interested...
Greetings,
Mike
10 september 2007 "susowa" wrote:
I began previous year thereby, however there are 0. (Ethernet+TCP/IP)
already completely as hardware with http://www.wiznet.co.kr and that I also
selected after pursuit for many years of the whole development.
In order to be absolutely independent from the hardware binding to, the
experimentation plate with ATmega and NM7010A-Modul (Easy TCP/IP of BASCOM)
is connected by PIO in bi-directional enterprise the haven A by reciprocal
interrupt mode with a haven of the AVR (thus 8 + 4 lines).
AVR will only Wiznet chip to serve and RAM interfaces in terms of hardware
to tie up, which actual programming stacks will Z80 computers to make, as
the Socket driver, the which in AVR normally runs, on which Z80 is
programmed, thus remains one just as by software flexibly, as if the chip
would hang directly on the bus of the Z80.
Which goes up to now. I developed the plate and tried everything out with
the NM7010A-Modul - which BASCOM examples (UDP, TCP, DHCP, HTTP) has
immediately (partly after the removal of lack in the BASCOM sources)
functioned. I could communicate by UART control of the AVR with the PC, i.e.
the Wiznet Internet chip functions!
Subsequently, I replaced the BASCOM software in the AVR by a self-written
variant, in order to realize the PIO binding. Functioned meanwhile also, I
can send/receive with my Z80 computer over the PIO, whereby the AVR the
posting and read instructions " Protokolls" (up to now plentifully
exaggerated designation with 3 possible instructions however for the moment
I do not need no more) to/of the Wiznet chip, thus PIO-I/O converts address
(RAM/register) reads/to write.
To the KC-meeting I demonstrated, by writing the network attitudes into the
appropriate chip registers and, afterwards one knew init instruction these
IP with the PC anpingen (echo makes internal the chip). So far is that now -
unfortunately since then the production of my KC-side holds me somewhat from
progress of the project.
Which is still changed and/or actual I will already continue not with the
NM7010A-Modul, but leaves themselves with the more current variant NM7010B+
(W3150A+Chip with current TCP/IP core), substantially simple and to program
uncomplicatedly than the first variant W3100A-LF on the NM7010A-Modul.
I have the NM7010B+ module already there and it fit also electrically on the
unchanged AVR plate, one must only 2 or 3 socket into one another stack, so
that it fits mechanically (somewhat more highly comes). A test is however
still pending.
Why I write that here so in detail - now with this chip each PIO able Z80
computer TCP/IP a binding should be possible in the home network. One can
open 4 connections parallel - that should be sufficient, come it well nobody
on the idea Z80 computers for applications of servers run will let - or?
Everything which Mike above at minutes called, is possible - my primary
goals essentially are apart from functioning UDP/TCP transmissions:
1. PING
2. DNS
3. DHCP
4. TFTP or equal ftp
5. ev. Telnet
6. and then I will at least times test SMB.
One can problem-free also which own small 8-bit-fair make - TCP transfers
only.
AND if someone should have come now on the taste - in the phase of the
conversion of standard minutes (1. - 6. or others) in Z80 code is naturally
fellow combatants in demand - if it everything functions in such a way, as I
introduce myself. According to plan it is to continue in October thereby and
make available then I the information evenly specified on
http://www.kc85.susowa.homeftp.net somewhat better prepared.
12 January 2008 "susowa" wrote:
From fun Ernst became - It's Done!
To 06.01. my KC85 under CP/M took up the first time contact by TCP with the
PC and chatted a little with one another both to have.
... functioning UDP/TCP transmissions
That is straight in work, whereby the TCP server on the KC85 is already
finished.
1. DHCP
2. PING
(3. DNS)
That is still planned, whereby I do not know yet whether 3. clean-comes also
into the test routine.
I will present the interface with software at the KC-meeting to Live and in
color 2008 of 04. until 06 April in Ballenstedt (resin). There is
registration information on the KC-Clubseite:
http://www.iee.et.tu-dresden.de/~kc-club/08/0802-01.HTML
21 May 2008 "susowa" wrote:
So, KC-meeting is past - meanwhile there was substantial progress, which was
demonstrated there particularly in the software.
Conditions at the end of March:
- are only missing naehzu finished Socket driver for the PIO interface in
Z80-ASM, the two DNS functions still
whereupon putting on applications also in ASM:
- Test functions for MAC/IP/UDP/TCP transfers
- DHCP-Client
- PING-Client
- TFTP server & Client in the simultaneous operation for max. 3 transfer
parallel
21 May 2008 "FanDjango" wrote:
TFTP server and Client is naturally extremely practical.
Congratulations to progress - I note the source for if I finally times am so
far sowas to try...
07 July 2008 "Ralph" wrote:
will also times always note the source...
Greeting Ralph
15 July 2008 "susowa" wrote:
Today was large actualization of the project on the homepage:
http://www.kc85.susowa.homeftp.net
The software is now no more KC85-lastig, with PIO at the CP/M CCU must one
only 3 things settle:
- KC85 on NO
- PIO I/O address register
- ev. terminal codes adapt
and the test routine translate again. All standard CP/M things of the SYSLIB
are usually settled. Who made thereby already times which, should thus no
problems have. To try I cannot do that naturally however the CPMNET.COM
without error message am produced and more can and I then for the CP/M
friends will not also do.
Who wants to copy it, nothing can announce itself, is however not published
because of the firmware with the desired MAC address to me, does not cost. I
took a MAC of an old 3Com ISA map for me, will not no more need I surely.
Much fun during the reading, one hears itself!
15.07.2008 "Ralph" wrote:
Susowa... well those are nevertheless prima prospects! but first times the
ZBIOS must run correctly... Greeting Ralph
15.07.2008 "susowa" wrote:
Small supplement still to above, to the download of files not over on the
left of of the menus on the right side, there give it every now and then
problems go with the access.
In the Top menu by DOWNLOAD the files pick out always above or naturally
with the search function.
Sorry !
EOF
Peter Dassow
Hi Emmanuel,
I do not want to start a philosophic discussion abot sense and nonsense
of such a project, but if you want to follow my thoughts about it,
follow my entry in my z80 blog at http://www.z80.eu/blog/index.php .
Regards
Peter
--
* More infos about vintage computers and CP/M - http://www.z80.eu
Mr. Emmanuel Roche, France
> I do not want to start a philosophic discussion about sense and nonsense
> of such a project, but if you want to follow my thoughts about it,
> follow my entry in my z80 blog at http://www.z80.eu/blog/index.php .
But why did you not publish, in the comp.os.cpm Newsgroup, those 5 messages?
Then, everybody would have read them... (How many people know that you have
a blog?)
A few comments:
You say that you are happy with a CoProc system. There was a card that
fitted in the Epson QX-10, enabling it to run MS-DOS 2.11. I was given one,
one day, and gave it to an American, since I simply could not understand the
interest of running MS-DOS when CP/M Plus was available...
(There was also the Epson QX-16, which had both a Z-80 and a 8086 on the
motherboard, but they are much more rare than the QX-10.)
Finally, about the "sense and nonsense of such a project", it is everything
except philosophy. On the contrary. It is technical. Every technology has
its advantages and drawbacks. For example, a computer can only do 6 things:
> Should I remind you that you can do only 6 things
> with a computer, be it a Sinclair ZX-80 or a Connection Machine:
> 1) word processing
> 2) programming
> 3) spread-sheet
> 4) database
> 5) communications
> 6) graphics
> As long as those 6 needs are satisfied, the computer is a
> useful tool. And there are/were standards for those 6 needs
> under CP/M: WordStar is obviously the standard for word
> processors; BASIC is obviously the standard for programming,
> MultiPlan is obviously the standard for spread-sheet, dBase II
> is obviously the standard for database; XMODEM is obviously
> the (lowest common denominator) standard for communications;
> and finally GSX is obviously the standard graphics system for CP/M.
And the only reason for a "TCP/IP stack for CPM" ("TCP/M", in sort) is that
TCP/IP is now the universal "protocol" for telecommunications. So, if we
want to continue using our beloved CP/M systems, that means that we must
find a way to have it running on our 4-MHz Z-80 CP/M systems. (Replace
XMODEM by TCP/IP.)
Apparently, there are 2 main TCP/IP implementations for CP/M:
1) KA9Q by Phil Karn in 1985, written totally in Aztec C (portable?)
2) CPMNET by "susowa" (what does mean "susowa"?) in Z-80 assembler (M80) in
2008.
The first one is in English, but there are so few comments that someone else
was obliged to do a documentation (known as "NOSinfo" because the name
changed after it became more used by ham-radio operators).
The second one seems to have 7 or 8 (long) files explaining what he is
doing/ has been doing. The big problem being that everything (even the MAC
files) are written in German.
So, it is up to you to choose which way to go.
Personally, I think that CPMNET is better, mainly because it is written in
Z-80 assembly language and not C. See?...
But I don't know German (I only speak 3 languages). So, at the minimum, I
would need an English version of the MAC files.
Mr. Emmanuel Roche, France
By the way, Peter, if you use KERMIT, is it true that there is a version of
KERMIT using TCP/IP?
Peter Dassow
Yes, of course, but not for CP/M, instead, for your "beloved" MS-DOS or
even for modern Windows XP computers with Kermit-95 v2.13 (which is an
excellent terminal emulator and telnet client, too).
I was suggesting my blog because I am NOT sure everybody here in the
newsgroup is interested in discussions about sense and nonsense (I wrote
this already).
For me a CP/Net "translator box" for old CP/M computer would be a much
more practical idea, or, what I've wrote in my blog, a
"KERMIT-serial-to-FTP-Ethernet" box would be nice.
Not an implementation of a TCP/IP stack for CP/M computers which
consumes a lot of memory but does not provide the user with all
abilities and the (needed) speed.
Kermit is more than only a file transfer protocol, because Kermit
provides you even with commands for the remote computer and some
additional functionality (not to forget the terminal emulation
possibilites). It's all what you need except an integration into another
(remote) file system.
Peter
--
* A blog about vintage computers and CP/M - http://www.z80.eu/blog
Mr. Emmanuel Roche, France
"Mise à jour du 28-07-2008"
That is to say: 28 July 2008...
This Web page, http://www.cnda-vitale.fr/ListXModem.php, lists the XMODEM
programs ACTUALLY used by a (very) big French administration...
So, this Web page lists the XMODEM programs running on IBM Clowns that
French companies dealing with this huge administration need to use, to
connect to the national information system.
30 years after the invention of XMODEM! (In my collection of DDJs, I have
the original article by Ward Christensen explaining the creation of the
first modem program, for an S-100 Bus system under CP/M.)
("Every technology has its advantages and drawbacks.")
There is no out-fashioned technology: once a technology works correctly, it
can works until the end of time.
susowa
wrote:
Hello Emmanuel,
this looks like a little discussion about my "KCNET" - I can answer
all of your questions in my (german)English too.
But up to your lines in this group there weren't any questions from
the CP/M Users - the first entry in the german CP/M forum (Gaby) was
in 09/2007 - no comments, no questions ...?
Why I should make all of the information in english also, when there
is no interest ?
> And the only reason for a "TCP/IP stack for CPM" ("TCP/M", in sort) is that
> TCP/IP is now the universal "protocol" for telecommunications.
This was exact the motivation, to begin such a project.
> would need an English version of the MAC files.
Why ? The ASM is english :-)
To Peter:
> ftp://ftp.ucsd.edu/hamradio/packet/tcpip/
This is only an IP-Stack - Not TCPIP and this is a very big
difference.
> also a "rerolled" version at http://www.kc85.susowa.homeftp.net/ named "KCNET", now adapted for a > KC85 and additional interface hardware.
This is very incorrect! I haven't adapted or rerolled something!
The transformation of the driver C-Sources from WIZnet to Z80-ASM was
done by myself, so I could not understand your statements - did you
read the GERMAN articels about the development of the "KCNET" ?
Now to the technical details of your blog-article:
> These tries consumes a lot of memory from the TPA of CP/M
I need 388 Bytes for the device-driver.
And for now exact 1711 byte for the socket-driver.
Take a CP/M with 50k TPA - you have 49 101 Byte for your Programm -
how many CP/M-programs do you know with such a size ?
> and the execution speed is awful
Is a RAM-RAM transfer speed of about 22 kB/s with a 1,75 MHz computer
"awful" for you ?
Wich CP/M-Device can write data with this speed?
It looks to me, that you didn't read the KCNET-articles in depth and
wrote your opinion down - you can do so, but it is not the reality and
it is not fair also - this is not a software-stack, but a hardware
stack with a conveniently software-interface to Z80-ASM.
So far - many greetings frrom
"susowa"
Peter Dassow
> [...]
> To Peter:
>
>> ftp://ftp.ucsd.edu/hamradio/packet/tcpip/
> This is only an IP-Stack - Not TCPIP and this is a very big
> difference.
I didn't say that your project is the same, but anyway, thanks for the
clarification.
>> also a "rerolled" version at http://www.kc85.susowa.homeftp.net/
>> named "KCNET", now adapted for a KC85 and additional interface hardware.
>
> This is very incorrect! I haven't adapted or rerolled something!
>
> The transformation of the driver C-Sources from WIZnet to Z80-ASM was
> done by myself, so I could not understand your statements - did you
> read the GERMAN articels about the development of the "KCNET" ?
I guessed you didn't wrote the whole thing from scratch. That should it
mean.
> Now to the technical details of your blog-article:
>
>> These tries consumes a lot of memory from the TPA of CP/M
>
> I need 388 Bytes for the device-driver.
> And for now exact 1711 byte for the socket-driver.
>
> Take a CP/M with 50k TPA - you have 49 101 Byte for your Programm -
> how many CP/M-programs do you know with such a size ?
Ok, let's clarify it now... just to have a network stack isn't enough to
do anything else but processing packets.
Also, what I now understand (I will try to correct this in my blog) is,
on the Z80 side there almost nothing but interfacing stuff.
>> and the execution speed is awful
>
> Is a RAM-RAM transfer speed of about 22 kB/s with a 1,75 MHz computer
> "awful" for you ?
> Wich CP/M-Device can write data with this speed?
No, that would be fast. But is all done with a RAM-2-RAM transfer ?
> It looks to me, that you didn't read the KCNET-articles in depth and
> wrote your opinion down - you can do so, but it is not the reality and
> it is not fair also - this is not a software-stack, but a hardware
> stack with a conveniently software-interface to Z80-ASM.
Ok, I take this over, it's a hardware stack with a convinient
software-interface. So it's a special kind of hardware interface just
for use with the KC85 ? I am a bit confused now, because Emmanuel talks
about a TCP/IP stack ...
> So far - many greetings frrom
>
> "susowa"
Anyway, I appreciate any efforts related with these old stuff, so please
do not understand I would like to reduce your work. Still great stuff.
Regards
Peter
--
* A blog about vintage computers and CP/M - http://www.z80.eu/blog
susowa
> Ok, let's clarify it now... just to have a network stack isn't enough to
> do anything else but processing packets.
You have much more than a network stack, you have a BSD-like Socket-
Interface ready to use the rfc-protocols, this is like call a bdos-
function in CP/M.
> Also, what I now understand (I will try to correct this in my blog) is,
> on the Z80 side there almost nothing but interfacing stuff.
Yes - in principle, there a 3 logical levels, low level for PIO-
communication with the commands of the KCNET-Protocol, second level
for alter the registers of the stack and third the socket commands.
For implementing a common rfc you need only level 3 for the
communication parts of the rfc.
I wrote the 22k CPMNET for testing the interface on all 3 levels in a
menu-driven program and it has already a DHCP-Client, PING-Client and
TFTP CLIENT+Server - with this little effort (Memory) you are ready to
transfer files in your whole network to and from any tftp-client or -
server and this with the given speed of 22kB/s (PIO-limitation) - your
CP/M computer has no chance, to write the UDP-Packets of 512 Bytes
with this speed, my HDD-Write-Speed is with ZSDOS/Z-System and GIDE
about 2-3 kB/s.
> So it's a special kind of hardware interface just
> for use with the KC85?
You can use the interface with a standard Z80-PIO, thats all. But you
must build the interface and you must have a PIO or assemble an
additional PIO in your Z80-System, thats your part of work. The CPMNET
is ready for use:
- set the symbol KC85 to NO
- register the PIO-adress of your system
- control used terminal codes on top of the program
Now make the COM and it should work - of course without guarantee from
my side, it is a hobby-project, not a commercial product.
We (KC-Club) are now developing a special modul for the KC85 - this
modul is a special kind of hardware.
Herb Johnson
> You have much more than a network stack, you have a BSD-like Socket-
> Interface ready to use the rfc-protocols, this is like call a bdos-
> function in CP/M.
>
> Yes - in principle, there a 3 logical levels, low level for PIO-
> communication with the commands of the KCNET-Protocol, second level
> for alter the registers of the stack and third the socket commands.
> For implementing a common rfc you need only level 3 for the
> communication parts of the rfc.
>
> I wrote the 22k CPMNET for testing the interface on all 3 levels in a
> menu-driven program and it has already a DHCP-Client, PING-Client and
> TFTP CLIENT+Server - with this little effort (Memory) you are ready to
> transfer files in your whole network to and from any tftp-client or -
> server and this with the given speed of 22kB/s (PIO-limitation) - your
> CP/M computer has no chance, to write the UDP-Packets of 512 Bytes
> with this speed, my HDD-Write-Speed is with ZSDOS/Z-System and GIDE
> about 2-3 kB/s.
>
> You can use the interface with a standard Z80-PIO, thats all. But you
> must build the interface and you must have a PIO or assemble an
> additional PIO in your Z80-System, thats your part of work. The CPMNET
> is ready for use:
> - set the symbol KC85 to NO
> - register the PIO-adress of your system
> - control used terminal codes on top of the program
> Now make the COM and it should work - of course without guarantee from
> my side, it is a hobby-project, not a commercial product.
>
> We (KC-Club) are now developing a special modul for the KC85 - this
> modul is a special kind of hardware.
"Susowa", you posted earlier that you were not sure if there was
interest in the KC85 work among English-speaking people. Speaking for
myself, I find your descriptions and discussion here very interesting.
The subject of networking and CP/M comes up every few years, in my
experience, in comp.os.cpm. So I think your work would be of interest
to English-speakers with CP/M interests.
If you would be kind enough to take your posted remarks and
discussions with Peter, and turn them into an English page for your
Web site; and add links to the programs and documents you mention;
then, I think you'll get more response.
I also suggest this, because it's getting harder to find other prior
Z80 and CP/M work on networking. KAQ9 was mentioned recently in this
group; I could not find actual software for it among the "usual" Z80
and CP/M archives which exist today. If it is on the Web it seems to
be hard to find. Consequently, Susowa, your site may be one of a few
Web resources still available on the subject.
Over the years, a number of German people have contributed to CP/M;
and Z80 and CP/M machines seem to have more support in Germany than in
many other countries including the USA. I will consider my own advice,
and see about a German Web page for my Web site's CP/M activities.
Herb Johnson
retrotechnology.com
Herbert R. Johnson, New Jersey USA
http://www.retrotechnology.com/herbs_stuff/ sales web site
-- old Mac, S-100, 1970's & 80's computers, 8-inch floppy
http://www.retrotechnology.com/ retro-technology home pages
-- S-100, CP/M history by "Dr. S-100"
-- other old tech in iron, glass, rock
domain mirror: retrotechnology.net
email: hjohnson AAT retrotechnology DOTT com
if no reply, try in a few days: herbjohnson ATT comcast DOTT net
susowa
thank you for such a kind of reply :-)
I followed your advice and made a quick extract from this discussion
so far in the project space of my website: go to Projekte -> KCNET on
the left side and open the first article in the list - there are now
direct links to some documents.
> The subject of networking and CP/M comes up every few years, in my
> experience, in comp.os.cpm. So I think your work would be of interest
> to English-speakers with CP/M interests.
I know - but up to today all projects will handle this difficult area
in software over a rs232 (most of them so far I know) - this makes no
sense with a 8Bit computer and some MHz.
In my opinion you need a fast common interface (like a parallel PIO)
and a hardware stack to handle all tasks up to UDP/TCP level, like the
WIZnet-Chip(s) - the only chip, wich can do that in the moment.
Then I can play with all of the TCPIP-protocols on basis of the whole
technology - not with the help of other programs on the application
level of the stack, I'm free in programming and can use it in my own
way, must not use a rfc but I think for beginning its better :-)
> be hard to find. Consequently, Susowa, your site may be one of a few
> Web resources still available on the subject.
No - this is my personal project-site for he KC85 Stuff of about 20
years since the last year, not only for CP/M or networking with CP/M -
this is now a very big part, but I think, I will realize my goals with
this interface, then this will change down to a normal level of work.
regards Ralf Kästner
no....@no.uce.bellatlantic.net
Glad I maintained it in a local archive. I'll have to zip it up if
there is someone that can host it.
Allison
no....@no.uce.bellatlantic.net
wrote:
>Hallo Herb,
>
>thank you for such a kind of reply :-)
>
>I followed your advice and made a quick extract from this discussion
>so far in the project space of my website: go to Projekte -> KCNET on
>the left side and open the first article in the list - there are now
>direct links to some documents.
>
>> The subject of networking and CP/M comes up every few years, in my
>> experience, in comp.os.cpm. So I think your work would be of interest
>> to English-speakers with CP/M interests.
>
>I know - but up to today all projects will handle this difficult area
>in software over a rs232 (most of them so far I know) - this makes no
>sense with a 8Bit computer and some MHz.
>
Rather than parallel why not SPI as implementing that is far simpler.
hard ware needed is an out put bit and input it and a birdirectional
clock.
>In my opinion you need a fast common interface (like a parallel PIO)
>and a hardware stack to handle all tasks up to UDP/TCP level, like the
>WIZnet-Chip(s) - the only chip, wich can do that in the moment.
>
>Then I can play with all of the TCPIP-protocols on basis of the whole
>technology - not with the help of other programs on the application
>level of the stack, I'm free in programming and can use it in my own
>way, must not use a rfc but I think for beginning its better :-)
There are a few PICs and other chips that can do the bottom layers of
the stack to the media level and save a great deal of low level
software. Also there are Ethernet chips that will do the work all the
way to packet buffereing so that the host doesnt have to be fast to
do the higher level work.
In the last few years the number of really tiny CPUs that have a
complete IP stack and even the interface ready to go are noteable.
I don't know about most systems referrcences but most of the common
hard ware here are 4mhz Z80 and that can if pushed move around
50-60Kbytes/second. If the device has the Z80sio/dart those can run
serial to 56K or faster and are limited only by the CPU speed. Going
parallel will not gain much speed over that. Its a matter of CPU
speed and cycles needed to do transfers. Of course with 6MHz,
8MHz or faster Z80s (or Z180s) then those limits go up proportionatly.
However if the eithernet inerface can buffer packets so that the host
runs at it's speed it will work smoothly and can even "feel"
responsive.
>
>> be hard to find. Consequently, Susowa, your site may be one of a few
>> Web resources still available on the subject.
>No - this is my personal project-site for he KC85 Stuff of about 20
>years since the last year, not only for CP/M or networking with CP/M -
>this is now a very big part, but I think, I will realize my goals with
>this interface, then this will change down to a normal level of work.
The beauty is that CP/M doesn't care how it talks to console,
printers, or storage only that it can.
Keep the good work going.
Allison
>
>regards Ralf Kästner
Hans Bus
<Snip>
>> I also suggest this, because it's getting harder to find other prior
>> Z80 and CP/M work on networking. KAQ9 was mentioned recently in this
>> group; I could not find actual software for it among the "usual" Z80
>> and CP/M archives which exist today. If it is on the Web it seems to
>> be hard to find. Consequently, Susowa, your site may be one of a few
>> Web resources still available on the subject.
>
> Glad I maintained it in a local archive. I'll have to zip it up if
> there is someone that can host it.
>
> Allison
There is a Something on:
ftp://ftp.funet.fi/pub/ham/packet/tcpip/ka9q/
I do not know if it is the actual stack or support SW.
regards,
Hans Bus
no....@no.uce.bellatlantic.net
wrote:
It may be where I got it from. the files are zipped but the sizes are
large enough.
Allison
>
>regards,
> Hans Bus
Hans Bus
>
> There is a Something on:
> ftp://ftp.funet.fi/pub/ham/packet/tcpip/ka9q/
>
> I do not know if it is the actual stack or support SW.
It may be where I got it from. the files are zipped but the sizes are
large enough.
Allison
> regards,
> Hans Bus
The file rcsdsrc.zip contains sources. the Makefile says :
# Makefile for KA9Q TCP/IP package for PC clones with Borland C
the Revision is 1.57 from May 9th 1993.
So, it is specific for PC's. There are 158 .c source files, so it is
quite a package. But the TCP/IP stack itself must be among them....
Regards,
Hans Bus
susowa
> hard ware needed is an out put bit and input it and a birdirectional
> clock.
in SPI-Mode. But you would need the same on the Z80 side - I have not
a SPI-Interface in my Z80-System but I have a so called Digital In/Out
Modul ready for such experiments and a PIO is simple enough for me.
> There are a few PICs and other chips that can do the bottom layers of
> the stack to the media level and save a great deal of low level
> software. Also there are Ethernet chips that will do the work all the
> way to packet buffereing so that the host doesnt have to be fast to
> do the higher level work.
Yes there are some very interesting projects, like http://www.sics.se/contiki/
or some implementations of software stacks with microcontrollers here:
http://members.home.nl/bzijlstra/
Why used Ben the same Chip for the newest project "Red Bokito" - it is
very simple to program and it works like expected, in my Interface
too. What the controller makes with the chip I can do with the Z80 in
the same way, all what I need is a simple and fast bridge to program
the stack with Z80-Assembler, my prefered language. This makes the
KCNET possible for me in my system now.
> I don't know about most systems referrcences but most of the common
> hard ware here are 4mhz Z80 and that can if pushed move around
> 50-60Kbytes/second.
Yes, now limits my 1,75MHz - System the speed, I think you can reach
about 50 kB/s with a 4 MHz System if the ATmega (my bridge on the
other side) can handle this. I can't test it.
> If the device has the Z80sio/dart those can run
> serial to 56K
The 56K are kBit not kByte.
> Going
> parallel will not gain much speed over that. Its a matter of CPU
> speed and cycles needed to do transfers.
I think it is a difference between 56kBit and 448kBit or 7 kByte and
50 kByte, by the way, for usability you need a minimum of about
7...10 kByte/s, this is my personal experience so far. Thats why I
prefer the parallel hook of the interface.
> However if the eithernet inerface can buffer packets so that the
host
> runs at it's speed it will work smoothly and can even "feel"
> responsive.
That is not enough, the handling of the packets between the layers of
the stack and TCP-Handshake for example is a time consuming and tricky
issue - all done by the hardware stack from WIZnet, I can and must do
only the rfc protocols in the Z80-system.
DHCP - I can't follow the send - receive messages of the client on my
screen, its to fast
TFTP - the data packets with the filedata are so fast, that the hdd
can't write them
PING - here you work on the IP-layer and must calculate the IP-
checksum on the host (Z80) for incoming and outgoing PING-Messages and
measure the time from send to receive - the time has a deviation of
100 ms, when you ping the CP/M Host while he is pinging by itself then
you can "see" the Z80 hard working, the answer times goes up to 120 ms
with spikes up to 400 ms
OK - I think enough information, I must continue my work in the next
time, I answer to all questions here ore per email but writing
comments consumes too much time in the moment.
regards Ralf Kästner