CPCWiki forum

Hello again,

While I have been waiting to get more parts to complete my first batch of the IDE/8255 interface, I have been looking at various 8-Bit ethernet interfaces and find one which uses the CS8900 chip.

A further search of the PDF for this chip shows that it is quite simple to create a interface with it.

I have begun to draft a version which uses again the 8255 (more later in future posts).

You can find attached the draft eagle file and associated PDF.

It seems quite easy to do, so hopefully the draft is all i need to get one working.

regards
rpalmer

Well, there was a presentation some years ago at a spanish meeting. So maybe some spanish guys can tell more here. It was the expansion card for the SF2, which includes an Ethernet port.
Up to now this expansion card can't be ordered. However I doubt that compatbility can be made between the two solutions. Dr. Zed did create that card. I heart nothing about it for a year or so. And I got no idea if it is still unter developpment or not. I try to find out...

hello TFM,

The SF2 card currently does not have an ethernet interface as seen in the attached picture i downloaded from prodatron's website.
It does include a PS-2 port for a mouse, so maybe that was what you were referring to.

I also look forward to the day when a CPC can communicate to the world via ethernet.

rpalmer

TFM refers to the ethernet card which was planned for the Symbiface. This is a picture of the prototype from the XzentriX 2007 meeting in Seeshaupt / Germany:

(http://www.octoate.de/wp/wp-content/gallery/xzentrix-meeting-79-992007/DSCF3322.JPG)

There was also a working SymFTP version:

(http://www.octoate.de/wp/wp-content/gallery/xzentrix-meeting-79-992007/DSCF3346.JPG)

Well, there were no big news since then, so I guess, they don't work on it anymore.

Well, roughly a year ago Dr. Zed told me that he is short before releasing it, but then he discovered a new hobby: horses. So I got no idea honestly.

I got myself an Arduino mega card with its ethernet/SD shield.

http://arduino.cc/en/Main/ArduinoBoardMega (http://arduino.cc/en/Main/ArduinoBoardMega)
http://arduino.cc/en/Main/ArduinoEthernetShield (http://arduino.cc/en/Main/ArduinoEthernetShield)


I wanted to turn this into an internet solution (or any other expansion stuff), but to be fair I don't have time to learn to code it at the moment.
(this use some moded sort of C/C+ language)
As it would need both the Arduinos to be coded and some OS on Amstrad to be done too...(web browser)

Also this card seems a little light on RAM/ROM... I may need to get myself some RAM/ROM board.
I was planning to get this for my Amstrad PLUS because :

-Cartridge : easy ROM box which is not connected to the extension port...(I have spare GX4000burninrubber cartidges to hack)

-Plus features : perhaps better for a web-browser GUI (HardSprites for pointer, Rasters interrupts for menus in mode2.... better palette)


Anyway such Protoboard may be quite interesting IMO...
This can also be turned into some soundcards (emulate a second AY or even a SID...) or whatever.

I always find it a shame that the Hardwareguys here produces their own custom cards... while generic do exist.

After all, they often put the exact same chips (micro controlers or whatever) on theirs, but loose the "generic and kustomisable" aspect due to their closed design.

Arduino mega (or any comparable stuff) are easy to find, not that expensive (quite a bit actually...) and solid multy-purpose cards.


Also I like the "shield" design...
Easier way to get more stuff in an actually more compact stacked/racked design.

Symbiface : why can't you simply connect/plug an existing ethernet shield on this ? ;)

other related topics :
http://cpcwiki.eu/forum/index.php/topic,1690.0.html
http://cpcwiki.eu/forum/index.php/topic,1805.0.html

Hi macdeath,

There are indeed many solutions to bring an ethernet to any micro-computer, but the one i wanted to build would allow for the access to the TCP/IP functions and buffers from within TCP/IP so that HDOS can use them as well, rather than have all of it away from the amstrad.

rpalmer

@MacDeath,
        the reason why most hardware designers avoid generic cards is due to cost. Although they are great for prototype or concept development, they are very expensive to use as a single solution, because they offer a little bit of everything. A small PCB developed just for a single purpose such as Ethernet / USB or whatever can sometimes be reduced down to less than 10€ component price, whereas an Arduino will set you back around 45€ just for the board, which you will still need to build an adapter for so that it can be connected to the CPC. If the project is intended as a low cost DIY project (as mine usually are) the Arduino is not an option.

@rpalmer, as I've said in a PM, nice project. Do you have a reasonably priced source for the CS8900A ? I've seen prices ranging from 3€ to 27€ !!

Bryce.

Quote from: Bryce on 08:18, 03 May 11
@MacDeath,
        the reason why most hardware designers avoid generic cards is due to cost.

I like the Arduino and have bought two as well, but there's a reason you don't use generic card for special solutions.


Let's see:

Your configuration (approximately)
Arduino Mega 2560 (the normal Mega is not produced anymore): ~49 Euro
Arduino Ethernet Shield: 33 Euro

That's about 82-ish.


Probably cheapest Arduino configuration (approx.)
Arduino Uno (as cheaper replacement to the Mega 2560): ~26 Euro
Ethernet-Shield for Xport/Wiznet (Adafruit) - Arduino compatible: ~14 Euro

About 40-ish.

(Prices based on Watterott online shop)


Perhaps you can shear off a few Euros if you keep searching for the best priced shop, but I doubt it. Not quite the cheapest config to put as an extension into a CPC. Besides putting a 16 MHz AVR to use next to a 4 MHz Z80 is a bit overkill.

Bryce is right, the Arduino is excellent for prototyping and experimenting, but an expensive solution to add to a CPC.

MaV

Due to my interest in robotics (and robot arms) I have a couple of Arduino boards knocking around.  I agree, they are very handy for generic prototyping - I can use them to do very different things from one day to the next.  As Bryce points out, it's an expensive option to then only use the Arduino to do something that would have been better to build custom hardware - my problem is, I'm actually not a hardware / chip / electronics guru, so I don't have the knowledge to know that I can get an XYZ chip for $x that will do what I need.  I usually build a concept with the Arduino and then google for what other people have done and then usually find a chip number and spec sheet.  mostly though the project doesn't go beyond the Arduino stage  ;D


I really like the idea of a CPC Ethernet card and the overlaying TCP/IP support (wasn't there a cpc tcp/ip stack project online once?).
I was previously running a Hiawatha web server on Puppy Linux, until the CF Card corrupted itself (and guess who didn't take a backup...) - I would "love" to replace that PC based setup with an Amstrad CPC running a much simpler version of this http://www.hiawatha-webserver.org/howto (http://www.hiawatha-webserver.org/howto)
I'm not after running amazon.com from my CPC but it would be a real geek-trip to have my own personal web server serving up some basic things from my Amstrad - static html pages with some images would suit me fine.


If memory serves me right, I recall writing my own web server (in C) a few years back, it handled very very basic things - if someone is going to build the hardware to make this happen, I'll be happy to prototype options for software    8)

yes indeed someone had wrote a tcp/ip stack and i have put it into a rom, so less main memory is used.
for links see other comments in this topic (it is still under development at the moment).

rpalmer

QuoteArduino is far too expensive to be used for a CPC

QuoteBut I have a pair...

QuoteYeah me too, they are so kool

So Actually everybody already got one as I see...  :laugh:
(ok not everybody but quite a nice amount of you indeed...)

Where is the CPC friendly library then ?
:'(

My point is that you don't get an Arduino protoboard to get it runnning one expansion only... but to have an actual library of ...many expansion (not all at the same time of course... I guess) as you see fit.


Then why those generic protoboards aren't supported at all by SymbOS/FuturOS or any Amstrad friendly application ?


So please mister Hardboyz... when you prototype your stuff, do some Generic version for commercial protoboard too at the same time...Even if not all the stuff you then put in your kustommade card are emulated...
This is still better than nothing and just need some cables. ::)

MacDeath my friend, usually I really enjoy your lyrics here, but sometimes it's too much to read  ;D

Quote from: MacDeath on 18:19, 03 May 11
Then why those generic protoboards aren't supported at all by SymbOS/FuturOS or any Amstrad friendly application ?

Well...
- SymbOS developpment has ended seemingly. PDT is a bit pissed off, because nobody creates apps for it - that's what I heart from a third person.
- About FutureOS: I don't know the mentioned Ethernet card, because I never heart about it. So up to now there is no support.

Support will be added as soon as more than 10 people use the same hardware (and as soon as actual CPC projects have been finished).

EDIT: Thank's to Bryce I could correct some errors in this post and btw: Great humor ;D

Then it would be cool to get some inquiry/pool to learn which Amstradist may own such Protoboards and which models.
:)

@TFM/FS: FutureOS is a Graphic OS for the Amstrad, much like SymbOS, you should try it out, it's really not bad at all. You can find more information about it here: http://www.cpcwiki.eu/index.php/FutureOS  :D

Bryce.

Quote from: Bryce on 19:28, 03 May 11
@TFM/FS: FutureOS is a Graphic OS for the Amstrad, much like SymbOS, you should try it out, it's really not bad at all. You can find more information about it here: http://www.cpcwiki.eu/index.php/FutureOS (http://www.cpcwiki.eu/index.php/FutureOS)  :D

Bryce.

Thanks for the link. I'll check it out!

Yeah but the GUI lacks colours IMO...

SymbOS is also betterly supported, new Addons are released each month.






(And i believed i was the only Troll here...)

Quote from: TFM/FS on 18:44, 03 May 11
Well...
- SymbOS developpment has ended seemingly. PDT is a bit pissed off, because nobody creates apps for it - that's what I heart from a third person.
- About FutureOS: I don't know the mentioned Ethernet card, because I never heart about it. So up to now there is no support.

Support will be added as soon as more than 10 people use the same hardware (and as soon as actual CPC projects have been finished).

Every OS will rise/fall with it's applications/games or whatever. I can understand Prodatrons attitude. Even in TFM/FS case I  admire his patience supporting/developing his fast OS. For none-coders or BASIC-is-a-difficult-program-language-freaks like me it's hard to program an app in assembler without an exact "how-to-guide":) ... even if ideas drops out of the head.
I've seen that it is possible to program via SDCC (together with a special-library) SymbOS-Apps. C could be feasible. Even in FutureOS you can also program via Small-C and some special "lib's".
So... the easier it is to create applications for a OS the more people will use it. It's an ergonomic matter (not for professionals of course - but for 'dummies'). Therefore SymbOS has a little visual advantage, cause' it take after an elaborate ergonomical design of high-paid psychologists (...this should not be a performance assessment!!)
... need more time for build programing experienced... damn, too late.
You can found CPC/IP v0.20, a TCP/IP stack for Amstrad CPCs at http://genesis8.free.fr (http://genesis8.free.fr). I think the old website has ended?
There's also a link (german website) http://www.icplan.de/#embedded (http://www.icplan.de/#embedded) with a DIY TCP/IP Stack based on a Z80 with 32K bufferd RAM, 32K ROM, parallel & serial interfaces (RS232) etc.

Sorry for getting offtopic, just for a moment...

Quote from: MacDeath on 19:44, 03 May 11
Yeah but the GUI lacks colours IMO...

Well, that's what we call Mode 2. It's a working environment, dedicated to show a high resolution. BTW: You can (or I can do that for you) change the colors in which way you want.
Mode 1 or 0 wouldn't allow to display 64 file-names at the same time. However, any kind of apps can be as colorful as you like.

Secret information: I have planned an alternative Desktop version, manly half a new OS (but compatible), its name will be FutureOS Fatul. It will provide a Mode 0 Desktop in simulated 3D. You will work only with icons that are arranged in 3 dimensions. However, the actual Desktop is still the most efficient Desktop I can imagine (in my weary mind).

Quote from: MacDeath on 19:44, 03 May 11
SymbOS is also betterly supported, new Addons are released each month.

Oh really, must have missed them for quite a long time ;-)

Quote from: hal 6128 on 21:19, 03 May 11
Every OS will rise/fall with it's applications/games or whatever. I can understand Prodatrons attitude.

Absolutely! The best OS has no advantage, if there are no apps which use it. On the other hand you can't code ALL apps by yourself. I must admit also for FutureOS only very few peoples did some software. So I have to do it, but I lack time  :(

Quote from: hal 6128 on 21:19, 03 May 11
Even in TFM/FS case I  admire his patience supporting/developing his fast OS.

Thanks a lot, I appreciate. Support will not end before my physical death 8)

Quote from: hal 6128 on 21:19, 03 May 11
For none-coders or BASIC-is-a-difficult-program-language-freaks like me it's hard to program an app in assembler without an exact "how-to-guide" :) ... even if ideas drops out of the head.

Right! And for OS developpers it's hard to create a good manual. Because you are too close and so you forget to mention a lot of important things.

Quote from: hal 6128 on 21:19, 03 May 11
I've seen that it is possible to program via SDCC (together with a special-library) SymbOS-Apps. C could be feasible. Even in FutureOS you can also program via Small-C and some special "lib's".

Yes, FIOLIB works with Small-C and somebody told me it works also with SDCC, I wish I would have more time to care about it.

Quote from: hal 6128 on 21:19, 03 May 11
So... the easier it is to create applications for a OS the more people will use it. It's an ergonomic matter (not for professionals of course - but for 'dummies'). Therefore SymbOS has a little visual advantage, cause' it take after an elaborate ergonomical design of high-paid psychologists (...this should not be a performance assessment!!)

SymbOS looks pretty much like Windows, so people can use it without learning much. However, IMHO I don't like Windows on a computer screen with limited resolution, because it just will not work with some apps. But this is obvious. So I preferred to create some new, however people seem not to like it much, because it's strange for them.

Quote from: hal 6128 on 21:19, 03 May 11
... need more time for build programing experienced... damn, too late.
You can found CPC/IP v0.20, a TCP/IP stack for Amstrad CPCs at http://genesis8.free.fr (http://genesis8.free.fr/). I think the old website has ended?
There's also a link (german website) http://www.icplan.de/#embedded (http://www.icplan.de/#embedded) with a DIY TCP/IP Stack based on a Z80 with 32K bufferd RAM, 32K ROM, parallel & serial interfaces (RS232) etc.

Thanks for the link! Now, to get on topic again, I really hope to see a working Ethernet card for the CPC in this year maybe already :)

Quote from: MacDeath on 18:19, 03 May 11
Where is the CPC friendly library then ?

Ok, I've given it a thought.

You don't need a library, these already exist for the arduino shields. You'll need glue code to establish communication between the shields and the CPC. That'll be the least of your problems. The CPC does not have any hardware that enables communication with the "outside" world.

Let's start with the Arduino Mega 2560 and the CPC expansion bus. Don't even think about the cheaper Arduinos, they lack the pins and the flash memory. For proper communication you'll need the data bus (8 pins), address bus (16 pins), MREQ, IOREQ (probably), RD, WR; and perhaps even one or two more.

That's about 30 pins (+/- 2 pins).

The CPC needs a ROM, which the arduino probably can emulate. I'm not sure how the CPC roms are initialized - I've forgotten that after all these years - but you'll have to do initialization + deliver the correct rom bytes via data bus if the Z80 asks for them. You'll also have to discern somehow if it is your emulated rom that is being addressed and not one of the many others.

Your code has to be fast as hell, since you're communicating low-level with the z80, so no Arduino C but proper AVR assembly needed. I'm still not sure, if that'll be enough.

And don't forget that your shields use pins as well, so you're probably able to use two shields at the most (I'm being optimistic here.)

MaV

My Arduino seems to have quite enough pins... even with its Ethernet shield on.

Concerning ROM, as I was aiming at a PLUS version, I just have to get a proper cartridge done (I have spare GX4000 Burnin' rubber carts to cannibalize...
Need some proper flash 512K eprom then.
This should be quite enough to get all the Amstrad may need in ROM..?
and get the Extansion port freed from additionnal ROMboard so only the Arduino is connected to it.

Quite more convenient IMO than a CPC old generation.

Also i have the proper 50way plugs (centronic) and a stock of spare flat cables (IDE cables).



I knew the Ethernet shield allready manage all the stuff/library, and that It only nned a good soft connection between the Arduino and the CPC.

There the one I have:
http://arduino.cc/en/Main/ArduinoBoardMega (http://arduino.cc/en/Main/ArduinoBoardMega)

Yet it is quite a bit short on built-in "RAM/flash/EEprom...
This Card is just there to do the link between CPC/PLUS and the ethernet shield, from what I thought.

Shields : I intend to use only the Ethernet/SDcard one (don't have any others)... Yet I know it can't use both ethernet and SDcards at the same time.

QuoteYour code has to be fast as hell, since you're communicating low-level with the z80, so no Arduino C but proper AVR assembly needed. I'm still not sure, if that'll be enough.

So the Arduino card can actually be programmed in assembly instead of pseudo C ?

Quote from: MacDeath on 11:37, 09 May 11
My Arduino has quite enough pins... even with it's Ethernet shield on.

Concerning ROM, As I was aiming at a PLUS, I just have to get a proper cartridge done (I have spare GX4000 Burnin' rubber carts to cannibalize...
Need some proper flash 512K eprom then.

I knew the Ethernet shield allready manage all the stuff/library, and that It only nned a good soft connection between the Arduino and the CPC.

I'm still not sure if the Arduino can handle the ports that quickly.

The data bus and adress bus make three 8 bit ports on the Arduino and they have to be read separately, since it's an 8-bit microcontroller. It also needs to discern whether it's the Arduino itself that's being addressed and ignoring all the other memory accesses.

Z80 reads/writes:
What the Arduino needs to do:
1) wait for the correct signal (interrupt handling or polling)
2) read the address bus (read two ports)
3) load correct byte (from ethernet) OR read the data bus
4) send byte


We're talking about multiple clock cycles per step for the Arduino.

Writing to the data bus means that you'll need to keep the port in a high impedance state (or input state and ignore the signals) until the AVR receives the right signals then change the port to input then send the byte. You might even need to check if the CPC's components are ready for your transaction. After that you return the bus to the high impedance state (or input). You need to do that to avoid bus conflicts which lead to indeterminable states. While it may be feasible for one port, it may not be so if you want to do the same with the address bus, but you have to in order to transmit the data from the ethernet card. Double the ports, double the work. And changing from input to output to high impedance might take too long for proper communication.

Basically you're emulating a part of the chip hardware in software.  ???

MaV

PS: I'm planning a CP/M board with an AVR and an 8MHz Z80 + SRAM. The problems are much the same, but I don't have to put up with the extra hardware of the CPC. The AVR will control be the multi-purpose peripheral device. Since the AVR is the only peripheral, I'll just check the IO pin for the correct signal. The value of the OUT on the address bus is the code to identify which action the AVR needs to take, while the data bus send the actual values if needed. Nothing to see yet, the project's still in its infant state. I may change them yet.

Quote from: MacDeath on 11:37, 09 May 11
So the Arduino card can actually be programmed in assembly instead of pseudo C ?

Yes, but it's a hassle.

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1188341312/14#14


It's probably better to buy a programmer and program the Arduino via AVR Studio in assembly (or C). You can always return the boot code to make it an Arduino again.

MaV

hello all,

I already have recieved 3 CS8900 chips to build into the ethernet boards as well as some 8255's, but I am waiting for the edge card connectors and PCBs to arrrive to begin building and then testing.

When I have completed the first build of the ethernet board using the cs8900 chip, it should be a simple matter to create a set of driver routines (read API's) so that the CPC can communicate with the outside world.

The source code for the drivers/APIs will be freely available so that others who wish to create apps (like a twitter app) can do so with relative ease.
I have seen the high level support for the chip, so it does not seem to much of a hassle to create the base foundation routines.
I have a great deal of experience with putting code into the CPC ROMs, so if anyone wants more info about what and how its done I am more than happy to supply them with the necessary details (although I imagine it is not that hard once they look at the drivers which will detail how ROMs are structured).

My first test will be to simply see if i can setup a PC with a server (like unbuntu with apache) which i can telnet into using the ethernet card and my converted TCP/IP in ROM S/W, along with a telnet app.

As for the card being usable in FutureOS, Symbos, or whatever there will no doubt some additional code required by the OS's to allow for the ethernet card.

It would be great to setup a CPC with my IDE/8255 and ethernet card as a network server and have people on the 'net accessing files...... HERE COMES THE CPC TO TAKE OF THE INTERNET..... LOL

rpalmer

Hello all,

Well I have finally been able to make an etched PCB prototype which can be used to build an ethernet board.

Lets hope that I can solder the cs8900 chips as the square which is top center of attached picture has about 100 small leads to solder.

There is a small error on the board, I need to use A10 as well as A5 to make the board behave properly.

I am still waiting for a number of parts before I can fully build and then test the board, so its only going to a short while before things start to really rock on.

regards
rpalmer

Nice... :) What are you going to use to drive it?

Looks good, did you etch it yourself or have it made? As someone who's done this (and messed it up) many times in the past, I can confirm that soldering 0.5 Pitch is a serious pain in the ass, all I can advise "use loads of flux!". And good luck.

Bryce.

Hello bryce,

Yes I did etch the board myself (using the toner transfer method) and it took me over two days to get that far.

I want to first build a prototype to iron out any bugs.  If it is not that hard then I will simply do it all myself.

I have tested my ability to etch the 0.5 mm pins on the IDE to CF adaptor and i feel i can do the CS8900.

To Gryzor,

I have already started to develop the drivers to be built into the drivers rom for HDOS.
Dont forget that I also converted TCP/IP to work from ROM, so all things going to plan it should work very soon.

regards
rpalmer

Don't forget to set a BBS up, eh?

hello all,


here is what the ethernet board is currently at.

Soon will be completed and this is when the fun really begin.... testing.

Draft drivers already created.

I have found that the PCB is quite hard to make given that the ethernet chip has very close pins. Several of the boards also had issues, which i hope have been resolved with this one.

rpalmer

OMG! You soldered SMD parts!  :o  Great work!!!  :) :) :)

Well I have finished putting all of the items onto the board.

However the led's and resistors (they are the vretical ones to the right of the led) are connected in the wrong order to Vcc.  The should have been connected with the resistor between the cs8900 and the led with the led connected to Vcc, I have them the other way around so I hope thats not an issue during testing.

rpalmer

They're just current limiting resistors. For an overly pedantic twat such as myself it would be wrong, but in reality it doesn't matter in the slightest whether the resistor is before or after the LED.

Bryce.

Quote from: Bryce on 08:32, 29 June 11
For an overly pedantic twat such as myself it would be wrong, but in reality it doesn't matter in the slightest whether the resistor is before or after the LED.

For a twat like me you need to explain what's "before" and "after" an LED supposed to mean, so that I may become as pedantic as you. :P

Let me ask a more "stupid" question here (... Redbox waits since years for that chance...). Now we have an Ethenet port at the CPC. Let's ignore the software side for a moment. My question is, what can we technically do with that port? (Connection to ? Communication with ?? Protocols ???). Maybe somebody out there can answer that silly question easy and precise? (A good answer will earn a personalized FutureOS version for free!).

Quote from: TFM/FS on 19:55, 29 June 11
My question is, what can we technically do with that port? (Connection to ? Communication with ?? Protocols ???).

Pretty much anything. People have been making webservers out of C64s for almost a decade already http://www.tomshardware.de/commodore-64-kommt-als-webserver-zurueck,news-4462.html (http://www.tomshardware.de/commodore-64-kommt-als-webserver-zurueck,news-4462.html) (building on stacks such as uIP http://www.sics.se/contiki/ (http://www.sics.se/contiki/)), and both platforms are ahead of what the ARPA-/Internet first came to life on - back in 1962!

Quote from: TFM/FS on 19:55, 29 June 11
My question is, what can we technically do with that port?

I want to be able to read this forum from my CPC! 8)

I just want to be able to log onto my server, click on attached devices and see 192.168.0.128 - Amstrad CPC6128 :)

Bryce.

Quote from: Bryce on 20:38, 29 June 11
I just want to be able to log onto my server, click on attached devices and see 192.168.0.128 - Amstrad CPC6128 :)

Make this 192.168.6.128 instead... ;)

Hmm... I see I get no easy answer here,... and I'm (sorry!) just not interrested in all that c64 crap.

hello all,

The interface has only just been built and have not started to test whether its working yet.

Well lets not forget that i converted the CPC/IP software to run from a ROM and can have configurable settings unlike the CPC/IP which is built with its settings hardwired in.

Once the software is shown to work with what has been converted, I will create a set of library like functions (such as open_socket, close_socket, etc) to interface into TCP/IP such that others can write there own software.

As for what this can do for us CPC users, well lets say that we can:

1. Possibly setup a web server using the CPC as the host,
2. Access web sites such as twitter (seen it done on a MSX url is http://www.konamiman.com (http://www.konamiman.com) , so its not beyond us to try),
3. Access a file servers using FTP,
4. Maybe in the near future setup a Chat service along the lines of MSN Messenger, and
anything else that people may conjure up that can be easily developed within the capabilities of the CPC.

rpalmer

Quote from: TFM/FS on 20:45, 29 June 11
Hmm... I see I get no easy answer here,... and I'm (sorry!) just not interrested in all that c64 crap.

Crap it's not, just because it saw first light on a 6502. The point is that with a TCP/IP stack, you can also make a CPC control your home appliances or model railroad, and talk to the Internet (including your iPhone ;)) on the other end, or spread its good news for the whole world to see.
Someone's got to say it: "Imagine a beowulf cluster of these!" :D

hmmm.... I wonder if I can connect my set of Arduino devices up to my CPC.... then when I am working away, I'll be able to communicate with my CPC & control the Arduino devices.  Sure I could use a PC, but it's a lot of hassle to setup the PC, the CPC would not only be cooler but much more energy efficient and my wife can restart it in 2 seconds :laugh: .
What sort of Arduino devices?.. I have gardenSensors that measure soil temp, moisture etc.. I could get the CPC to control the ability to water my garden when it needs it and where it needs it.  Not the most obvious use of CPC Ethernet, but certainly something I plan to make a start with and then grow the inventions from there  ;D

I see the ethernet port as an easy way to copy files or entire disks from the PC to the CPC.


If you don't want to mess with an old PC and your 3" drives, you could simply create a program that reads a dsk image from the PC and writes the disk on the CPC. It could also be used to make images of disks and store it in your pc directly with no further complications.


That's my two cents.  ;D

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

I mean, massive multiplayer online RPG anyone ?

;)

WoWCPC ?

Bryce.

Quote from: MacDeath on 11:34, 30 June 11
The real question is : what kind of game should be developped for this ?

I mean, massive multiplayer online RPG anyone ?

;)

You're too high above the clouds ;)


Serious: I think a simple small network game would do well with this.

QuoteI mean, massive multiplayer online RPG anyone ?

An ASCII based MUD on CPC, yeah!  :)

A jabber client would be very nice, too

A lot of arguments and ideas here remember me about the CPC Booster+

Now, the question is, what can this card do, that the CPCB+ can't?

Since I'm not familiar with Ethernet (up to now the CPC has none!) and nobody like to tell me exactly what we can do with it, I just stick with the "CPC in the internet" idea.

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.

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 (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 ;D .

rpalmer

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

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.

DSCF0004.AVI (http://www.youtube.com/watch?v=6X9WkenU_vQ#)


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

regards
rpalmer

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

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

Quote from: hal 6128 on 10:01, 04 July 11
...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?

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

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

rpalmer

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

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

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

As for the problems: maybe consider an alternative OS?

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

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.

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

Quote from: MacDeath on 11:34, 30 June 11
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!!!

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

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)  :o

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

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

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

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

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

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:

Quote
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/ (http://spectrum.alioth.net/svn/)

lol

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

Hi rpalmer!

Great work you are doing.

I will be a week out, but after I'm planning to start making some testing board for my WIZ811 based card... I hope to come with good news!

MacDeath!!! What about your Arduino ethernet? Any news??

hello everyone,

I just called into say here is the first draft of the TCP/IP documentation. It has been time consuming to get much of the descriptions correct to match what the cod has been assembled to be.

There is still (or appears to be) quite a bit of information to be included, but for the most part this document goes into some depth about the API.

rpalmer

Really good work, nice to see you're doing it in such a comprehensive and open way.  :)

Great job rpalmer... I am spiritually supporting your action  :P
As it was said above, static addresses are largely enough for a TCP IP network, DHCP will never be needed to my sense.
Moreover, before having TCP or even IP, may we have some simple Netbios packeting ? :)

@rpalmer (http://www.cpcwiki.eu/forum/index.php?action=profile;u=379): Are you still working on the project? Any news?

yes and no

I have been developing cpc web browser to make use of the ethernet card along with TCP/IP development.

I am in need of developing a new card which is needed to have expanded memory as well as an ethernet interface as the web browser needs memory and my cpc only has the d'tronics 256K silicon disc memory module. The 256K memory part is enough, but if web pages take too much of it it likely cause issues, but if the memory is expanded to 2 MByte it will less so.

The new card is expected to have an SPI interface for the ethernet chip and SD card slot on one side and 2Mbyte memory expansion on the other, but at the moment (with limited time during any working week) it is slow going.

rpalmer

It's very good news. It's great that you are developing a web browser. It's great that you are designing this new card. It will be a superb extension to the CPC :).

Will the web browser be on ROM on the board?

Gryzor,

The browser will have the HTML engine in a ROM, but the rest is loaded from disk.

rpalmer

I have gone through the PAL for a 2 Mb RAM expansion portion of the next ethernet / SD / memory card.

Attached is the simplified schematic and  truth table (PAL).

The PAL is configured for 2 Mb SRAM chip (See e14 at http://au.element14.com/webapp/wcs/stores/servlet/Search?catalogId=15001&langId=43&storeId=10184&categoryId=800000000175&st=SRAM&pageSize=25&showResults=true&aa=true&pf=111871607 (http://au.element14.com/webapp/wcs/stores/servlet/Search?catalogId=15001&langId=43&storeId=10184&categoryId=800000000175&st=SRAM&pageSize=25&showResults=true&aa=true&pf=111871607),111871608).

The PAL will change A14/A15 as per dk'tronics memory handling and cause a propogation delay for /RD, /WR and /MREQ. RAMDIS is set if expansion RAM is requested else it is cleared and SRAM control are set to disable access.

rpalmer