WANTED: Translator from German - CP/M

This is a discussion on WANTED: Translator from German - CP/M ; Ok. So, I have found a Web site which contains a CPMNET program... 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" ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: WANTED: Translator from German

  1. WANTED: Translator from German

    Ok. So, I have found a Web site which contains a CPMNET program...

    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




  2. Re: WANTED: Translator from German

    Hello.

    Mr. Emmanuel Roche, France wrote in message
    <48897099$0$946$ba4acef3@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?).


    http://babelfish.yahoo.com/

    Greetz, Katzy.



  3. Re: WANTED: Translator from German

    Project - KCNET
    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




  4. Re: WANTED: Translator from German

    Project - KCNET
    Written of Ralf Kästner
    Thursday, 24 January 2008

    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)



  5. Re: WANTED: Translator from German

    http://forum.z80.de/showtopic.php?threadid=261

    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-...8/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




  6. Re: WANTED: Translator from German

    Mr. Emmanuel Roche, France wrote:
    > http://forum.z80.de/showtopic.php?threadid=261
    >
    > CP/M-Forum » Softwareprojekte » IP Stack im CP/M, wozu? » Threadansicht [...]


    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

  7. Re: WANTED: Translator from German

    Hello, Peter!

    > 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.

    Yours Sincerely,
    Mr. Emmanuel Roche, France




  8. Re: WANTED: Translator from German


    By the way, Peter, if you use KERMIT, is it true that there is a version of
    KERMIT using TCP/IP?

    Yours Sincerely,
    Mr. Emmanuel Roche, France




  9. Re: WANTED: Translator from German

    Mr. Emmanuel Roche, France wrote:
    > By the way, Peter, if you use KERMIT, is it true that there is a version of
    > KERMIT using TCP/IP?
    >
    > Yours Sincerely,
    > Mr. Emmanuel Roche, France
    >


    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

  10. Re: WANTED: Translator from German

    I had the curiosity of searching for "XMODEM"... and found a Web page dated:
    "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.

    Yours Sincerely,
    Mr. Emmanuel Roche, France




  11. Re: WANTED: Translator from German

    On 29 Jul., 10:52, "Mr. Emmanuel Roche, France"
    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"



  12. Re: WANTED: Translator from German

    susowa wrote:
    > [...]
    > 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

  13. Re: WANTED: Translator from German

    On 29 Jul., 22:42, Peter Dassow wrote:

    > 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.

  14. Re: WANTED: Translator from German

    On Jul 29, 5:50 pm, susowa wrote:

    > 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

  15. Re: WANTED: Translator from German

    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.

    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

  16. Re: WANTED: Translator from German

    On Wed, 30 Jul 2008 10:48:43 -0700 (PDT), Herb Johnson
    wrote:

    >On Jul 29, 5:50 pm, susowa wrote:
    >
    >> 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.


    Glad I maintained it in a local archive. I'll have to zip it up if
    there is someone that can host it.

    Allison
    >
    >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



  17. Re: WANTED: Translator from German

    On Wed, 30 Jul 2008 14:03:25 -0700 (PDT), susowa
    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



  18. Re: WANTED: Translator from German

    no.spam@no.uce.bellatlantic.net schreef:

    >> 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

  19. Re: WANTED: Translator from German

    On Thu, 31 Jul 2008 09:53:31 +0200, Hans Bus
    wrote:

    >no.spam@no.uce.bellatlantic.net schreef:
    >
    >>> 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.


    It may be where I got it from. the files are zipped but the sizes are
    large enough.

    Allison

    >
    >regards,
    > Hans Bus



  20. Re: WANTED: Translator from German


    >
    > 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


+ Reply to Thread
Page 1 of 2 1 2 LastLast