CPC Ethernet card development.

[HAL6128]

The CPC+ Booster can communicate over ethernet protocol (network access layer). From hardware side it uses full/half duplex technique. TCP/IP is built up on four layer for handling (e.g. transmition, securtity, redundancy) data back and forth, where the first layer is the network acces layer. If I've understand it right the CPCB+ is technically able for internet. Also the prototypes of the SF3?
But there's a lack of applications. If I've understand right so far it's only a matter of people's anticipation and the boundary conditions of the cpc how good and how far those apps will go.
We're talking about programming, right? The ethernet card of rpalmer is technically not the focus.

[rpalmer]

it should be noted that the CPC Booster/Booster+ uses the RS232/RS485 to perform serial communication.
This type of hardware is becoming rather difficult to get hold of to connect a CPC to a network here in Australia (I suspect the same is true elsewhere).

As for programming applications to use the ethernet card, well lets say that if standard functions can be created using a library for something like C then it would seem feasible to create a web brower like "Lynx" (an ASCII only browser, url is http://lynx.isc.org/lynx2.8.7/index.html).
hmmmm that seems like a good project to take on as well, to get web browsing on a CPC .

rpalmer

[HAL6128]

...hmmm, right. For direct ethernet communication an adapter / converter out of the CPC Booster is needed and quite expensive...

[rpalmer]

hello all,

Well it looks like my 3rd ethernet card finally appears to work.
The previous  2 cards were not connected correctly and so were cannabolised for parts (execpt for the cs8900... to many connections that ere too close together).

The first test was simply to boot the CPC with the card no connected to the netbook.
Next connect the ethernet cable to both machines and simply see if the "LAN" light was lit all the time, while the "Link" light flashes showing that the network was trying to get the CPC-Enet MAC address.

You can see all this in the youtube clip.




My next phase is to now get the drivers and TCP/IP S/W Rom to work.

regards
rpalmer

[norecess]

@rpalmer Congrats!


On my Amiga 600, there is software to do :
- emailing
- IRC client
- FTP browsing
- Link-style browsing


IRC client should not be that hard to implement, once the TCPIP stuff is there.

[Gryzor]

Pure magic Slowly a super-CPC is taking shape...

[TFM]

...hmmm, right. For direct ethernet communication an adapter / converter out of the CPC Booster is needed and quite expensive...

Wouldn't it be just a MODEM?

[rpalmer]

I been some time since my last post regarding the CPC ethernet card development.

I have been busy trying to get the device drivers coded up and now it looks closer to completion and is more modular to make understanding it easier in the future should anything go wrong (hopefully not never, but never say never).  It has been quite difficult as I had to take into consideration the interfaces with TCP/IP, Data Packet management between TCP/IP and PPP/SLIP, ethernet protocol for PPP (i.e PPPoE)  and ARP and the H/W driver itself.

I have also been correcting TCP/IP (ROM) so that the protocol handling (SLIP and PPP) are not part of the base source code, which means the code now handles all data via TCP/IP packets rather than byte streams as was previously coded.

The PPP/SLIP is now part of the drivers rom which makes it possible to include more into TCP/IP (there is now about 2K of ROM space).

All of this now makes it possible to implement TCP/IP using any serial communications device the user desires (assuming the actual device driver is available).

I have already included an API interface for the standard TCP/IP routines commonly found on the net, but some routines do nothing while i work out how to implement them.

I am now about to start the testing phase and it looks good on the surface.  My first test will simply perform hardware initialisation and to verify the initialisation data is correct in the H/W.

more will soon follow.

regards
rpalmer

[rpalmer]

well there is now good news.

After i slight hack of the interface (the RESET line to the cs8900 was in the wrong state every time i changed 8255 modes), I have managed to get the first series of test working. I also added READ/WRITE LEDS to see if read/write was working (these will not be on the release version).

I must say that until I found the RESET line to the CS8900 was incorrectly set I kept getting no where with the testing as the device was constantly being reset!  I also found that the A0/A1 lines of the 8255 were not connected to A8/A9 respectively but with A9 connected to A0 and A8 to A1 (man was that a bugger to find out).  These issues has been corrected in the PCB drawings so hopefully they are be a thing of the past.

The tests to date that worked are:

1. The perform a simple reset of the CS8900 and check its status.
2. The update the CS8900 with a MAC address and read that MAC address back.

The second test is a great leap forward (woo hoo!) as that means that only the protocols of handling the CS8900 are the main barriers left.

The next test is to perform ARP (Address Resolution Protocol) with my netbook to get its MAC address, so that the ethernet card knows who to communicate with.

Once the ARP testing is complete, my next test will be to get TCP/IP fully checked out and to telnet into the netbook and after that a test connection with my ADSL modem with a login session with my ISP.

LETS HOPE TESTING GOES WITHOUT ISSUES 

rpalmer

[qbert]

Fine... work in progress I see.
I'm following your project since the beginning 

[rpalmer]

hello,

I have managed to get some parts of ARP to work (i.e send the request and receive the incoming messages).  However, the netbook i tested with wanted to perform DHCP and that means it is expecting a server to respond, which my system is not.  This means I cannot telnet into my netbook, damn!

DHCP is to allocate IP addresses before ARP starts (from what i can see from wiki).

So for now the card can send ethernet packets and handle received packets.

Looks like I am going to have increase the scope of functionality to get the whole system up and running as I had intended.

rpalmer

[Gryzor]

Telnet... ooh, that would be ueber-geeky!

As for the problems: maybe consider an alternative OS?

[rpalmer]

hello gryzor,

I don't think a different OS will help, as most of the new ones (windows/Linux) are developed with newer or the latest standards for TCP/IP.

I have installed a PC with Ubuntu Server, but i don't know if the server programs are started on startup or whether they are setup first and the manually updated into the normal startup of the machine.

if however, i get DHCP to work with my ADSL modem, then perhaps I can have some measure of success without telnet.

rpalmer

[Bryce]

Well you can turn the DHCP off on the Netbook and give it a fixed IP address. Alternatively, to test the CPC Ethernet part, you could install a small Linux server so that it serves IP addresses (if the CPC Card is set to DHCP).

Bryce.

[KaosOverride]

Hello people!

Glad to see all of you want an ethernet for CPC, like me

After watching Denyonet for MSX and Spectranet for ZX (both based on WZ5100 chip), I'm testing with the complete module version for this chip , WIZ811MJ

It has a full TCP/IP stack built-in, so most work is made out of the CPU. Just initialize the WIZ(Ip, Gateway, mask), destination IP, port, and just read and write data with little or no care of the connection.

I have choosen the indirect mode for this chip ( 4 IO ports) because direct mode is memory mapped and can make some conflict with memory expansion...

So my objetives is to make an easy board for the module, which should be plugged in and ready to work, almost at low level...

There's full source for Spectranet and Denyonet ROMs so in some place in the future a port could be done. Also I can ask for some help to the coders if needed. My best candidate is Spectranet's ROM because has a near BSD sockets compatible API so porting of FTP, TELNET, WGET, simple IRC and so more will be easier.

I don't want to compete with no project, I think it's good to see many people with the same goal.

The future hardware is not defined to be an adapter for the module or a new design with the raw chip... but for testing I think the module helps a lot

I honestly wish good luck with all these projects!!

[KaosOverride]

The real question is : what kind of game should be developped for this ?

I mean, massive multiplayer online RPG anyone ?

I remember that TTracer supports serial interface link between 2 CPCs for a versus... So maybe it could be patched with a pre-loader to initialice the TCP/IP, setup the socket with the other CPC, load the game and replace the serial dialog ingame with a routine for the read/write of data. should be transparent, almost with a self stacked chip like the WD5100

Just an idea!!!

[Gryzor]

Now we'll need someone with a CPC willing to leave it on, plug a hard disk or some mass media on it and start a BBS...

[Ynot.zer0]

I'm happy to help (leaving CPC on).  I also have an eBox 2300 running puppy linux that could potentially be linked to it (as it connects to the wifi network).   let me know via PM if you want me to test / setup anything.  (I have a work server humming away in the garage 24/7, so having a CPC next to it would be no problem) 

[rpalmer]

I have also started to create an API interface for TCP/IP so that people can create applications using standard call interfaces.
The API interface contains most of the standard TCP/IP calls seen in many programs written in C.

This will no doubt mean there is going to be lots of testing of the API, but also a means for people to create whatever they think is possible on a CPC.

I am getting closer to getting the complete TCP/IP system up and running, but alot more work is needed so that the API works as seamless and as easy as possible.

And if it seems to go to plan, I may look at creating a simple application using the API (like getting the time from a server) to show off the possibility (such as a file server or BBS or whatever)

rpalmer

[KaosOverride]

Hi rpalmer

Glad to see you have the project in so advanced state. If I have understood good, you have ported the CPC/IP core to ROM and start an API to link the application to the core, then interface it with a driver for your ethernet.

Taking as reference the MSX idea of an unified API for rs-232/PPP, Obsonet ethernet (TCP/IP in the Z80 side) and DenYonet (TCP/IP in the ethernet card), maybe is time for thinking if we can do something like that for CPC and make the same executable run without changes in "any" cpc ethernet interface we can develop...

This is my idea...

You got the CPC/IP core in ROM, you are making an API to interface between the executable and the ROM... Tell me if this could be possible...


At the application side, a "library" with the API calls is statically linked. This could be merely some jumps to the ROM real calls. Also reserve some RAM for buffers

At the ROM, an array in a known possition with the in-ROM offsets of the functions, and when the application loads, the linked library autoupdates that offsets in RAM, autopatch, so when a function is accessed, it jumps to the correct offset.

Why all this, this way? Because with a ROM template, with the functions empty of code, can be recoded with any kind off hardware access. Software TCP stack will use the CPC/IP core and speak to the hardware, but TCP stack in external hardware (Arduino boards, WIZNET, any kind of cpu offload TCP...) can code their own ways to access the chip and give the data for making the function.

This way the same application will run without changes in an RS-232/PPP connection, your card, and anything else any CPC user could interface for ethernet.

Also new hardware drivers may be coded easier. Each hardware just needs it's own ROM, no changes at the application side.

In the offset Matrix you could also put some kind of "API identification" string for scanning purposes, and other string with the hardware "name" so if more than one device is present, the user could select which one use. for example "CPCIP ROM" for all the ROMS, and "RS232/PPP" for serial, "CS8900 ETH" for your card, "ARDUIN ETH" for Arduino device, etc...

With this idea, the program is run, searchs for ROMs, finds one, the API library in the program points to "nowhere", so the ROM is readed and the library is patched in RAM to what ROM and what offsets are each API call redirected. Then is just work of each ROM to use the CPC/IP core and then send it to a direct driven ethernet or serial port (MODEM), or redirect the data to an external TCP/IP chip of any kind.

Don't mind if there are many different ethernet projects, if each team makes the template ROM work with their hardware then all we win.

Please, when coding the API, take on mind this suggestions. Maybe you can code it at your own and the other teams just make a compatible ROM from scratch, but this way a lot of work could be avoided.

If there is enough room for all the drivers in a single ROM, so the array will be longer, with a segment of offsets for each "driver" and depending of the hardware, autopatch with the correct range of the array...

Maybe this discussion should be made later, but I think all of you will like it.

Thanks for all this long-epic-reading

[TFM]

Agreed! And it's - as I'm preaching since a long time - very important to have clear standarts for new hardware. If three people are developping such an Ethernet card, and if we need therefore three different software solutions for them, then not one of them can be that good as if all would work together. Further if somebody likes to developp software for new hardware, then it makes only sense if you have at least a minimum number of users.

So I would like to ask all actual and future ethernet-card developpers to come together and define common standarts :-D

That way we will always stay ahead ;-)
CPC                                                                       c64

[rpalmer]

I agree that a common standard needs to be developed in order for the base system to become viable across platforms, however there are unique differences that simply cannot be overcome by the standard.

For example, the MSX has a different memory configuration and limitations to that of the CPC, so buffer management may be different.

I have produced a picture of how TCP/IP on ROM works with applications and hardware, so this may help to understand how i envisage the system would be working.

The API interface which i have created uses the same names as that for UNIX/POSIX interface with limitations given the scope of functions I cannot implement in the space I have available. The use of standard named functions and their implementation makes it possible for existing software to be ported.

rpalmer

[TFM]

Thanks!!! Ok, let's focus on (future) standarts for CPC only ))

[KaosOverride]

Hi!

Well, when I was speaking about MSX, I was remarking the fact that they have 3 ways to connect to Internet, 3 hardware flavours, one is RS232/PPP, other an ethernet card with software TCP engine, and last the ethernet card with built-in TCP hardware, and the library makes possible to use the same executable with these 3 hardwares without recompiling.

Yes, the CPC standard should be made only for CPC, because each machine has it's own ways to manage hardware and memory. Not my intention to take the MSX project and make the CPC one source code or any other way compatible.... just take the good ideas like the hardware independent programs through the API.

By the way...

Spectranet API for Z88DK:

The main functions that will be implemented for all languages are:

    socket (HLCALL 0x3E00) Creates a new socket.
    bind (HLCALL 0x3E0C) Binds a name to a socket (i.e. sets the port).
    listen (HLCALL 0x3E06) Tells an open socket that it should listen for incoming connections.
    accept (HLCALL 0x3E09) Accepts a connection that has arrived on a listening socket.
    connect (HLCALL 0x3E0F) Connects to a remote host.
    recv (HLCALL 0x3E15) Receives data from a socket (SOCK_STREAM)
    send (HLCALL 0x3E12) Sends data to a socket (SOCK_STREAM)
    recvfrom (IXCALL 0x3E1B) Receives a message from a socket.
    sendto (IXCALL 0x3E18) Sends a message to a socket.
    poll (HLCALL 0x3E1E) Checks for new data or a status change on an array of sockets.
    pollfd (HLCALL 0x3E24) Checks for new data or status change on a single socket.
    pollall (HLCALL 0x3E21) Checks for new data or status change on all open sockets.
    close (HLCALL 0x3E03) Closes a socket.
    gethostbyname (HLCALL 0x3E27) Looks up a host by DNS name.

Interface configuration

A number of functions are provided for configuring the interface. These are used by the after reset/power up routines, and the DHCP client. There are matching routines to get information on how the interface is configured (for example, to allow a program to find the IP address that the interface is set to use).

    sethwaddr, gethwaddr (IXCALL 0x3E51, HLCALL 0x3E54) Sets and reads the MAC address.
    ifconfig_inet, get_ifconfig_inet (IXCALL 0x3E48, HLCALL 0x3E6F) Configures the IP address.
    ifconfig_netmask, get_ifconfig_netmask (IXCALL 0x3E4B, HLCALL 0x3E72) Configures the netmask.
    ifconfig_gw, get_ifconfig_gw (IXCALL 0x3E43, HLCALL 0x3E75) Configures the default gateway.
    deconfig (HLCALL 0x3E57) Deconfigures all IP settings.

Looks like the one you have made rpalmer!!!!

So if yout API is simmilar, we have got source code for TELNET, PING, FTP, TWITER, IRC client, WGET....  for Z88DK!!!! : here http://spectrum.alioth.net/svn/

lol

[rpalmer]

hi KaosOverride,

The API functions i have implemented will only partially perform all of the API interface functions. Those not implemented can be see in the previous post attachments.

The TCP/IP on ROM for the CPC currently has PING and TELNET as internal commands, so it leaves less room for all API's. However, if these are recoded for use via the API as externally loaded apps then there is room for more complete API's.

I have also coded up DHCP, so again it too leaves less for API functions. The DHCP will setup what your specific functions perform for configuration like gateway, subnet mask, etc.

As for configuration of the CPC system, this is achieved via a file (assembled to a binary) and loaded (see attached file).

As time progresses I will no doubt create a much more detailed document about the API's and what limits are on them.

I look forward to the time where external applications can be developed across a variety of platforms using the common standards we have developed/discussed.  They may not change the world, but they sure can show that these old machines still have some life left in them to fight the big boys (MS, Apple, cough cough).

Rpalmer