Should there be a CPC 'ISO"?

[Badstarr]

Hi guys!


The thought occurred to me today, after looking at some of the DIY hardware projects, specifically the IDE projects (I have always wanted a Hard Disk Drive for my CPC). Some of the threads on here associated with said projects point out that there are varying standards for hardware and software so I was wondering if maybe a group of hardware shooting stars on here could act as a sort of standards approval board?


I'm not exactly sure how it would work but maybe a CPCWiki seal of approval could be given if the hardware is designed to work with a particular driver or OS. So a definite standard is decided on the software side and the hardware geniuses build to be compatible with it. I guess the users who bolt on extra modern hardware may not represent the average user, but when new software is written it could be assumed that a standard set of devices could be present and when it senses them it can use them.


The other way of looking at it is, there are plenty of existing Hardware projects already on the wiki, so a poll could be made to decide on which ones are going to be considered the standard ones based on the usefulness and ease of build. Obviously, I wouldn't want creativity to be stifled!


Its just an idea, what are your thoughts?

[robcfg]

Always look at the 'Bryce' side of life... 

[Badstarr]

lol, I know, Bryce's projects set the standard!   I'm just wondering if there should be a degree of formality, especially when it comes to other projects. I guess so that if you build a particular project you know people are coding for it. I remember viewing TFM/FS videos showing video playing on a CPC and thinking it was really cool and if you could count on a fair few people having the correct hardware attached that sort of thing could be incorporated into games etc.

[Gryzor]

While it's a great idea, I think that at the current development levels it would either be ignored or inhibit further development. It's not like we've got zillions of projects, so I don't see any particular dev sticking to a spec.

But maybe I've got this wrong. What would be in the spec? (ooh, let's call it ISO6128? )

[Bryce]

Firstly, thank you for your words of support. Here's my two cents:

The only hardware that would need standardising would be hardware that requires a particular address space. So things like the S-Video Modulator don't need to be considered. Some of the things that do need particular addresses were already kind of standardised by Amstrad. The MegaFlash for example would only work using the Sideways ROM addresses that Amstrad defined, otherwise the CPC would never find the ROMs. The same can be said for RAM expansions. Where it gets difficult is with things like harddrives. Even back in the 80's every manufacturer seemed to do their own thing, which is why we're in the mess we are now. The only sensible thing to do would be to assess which of the 80's hardware standards for HDs was supported the most with software and choose that standard for future HD projects. This is what I did with the AMX Mouse Adapter, the software was there, so the hardware was made to fit existing software. Unfortunately I didn't own a HD for my CPC back then, so you will have to ask others about which one was best supported. Other hardware such as Speech synths also did their own thing, but the software support doesn't reflect the popularity. More people had DK Speech Synths, but the SSA-1 was better supported, so what do you choose?

At the moment, I refer to the I/O port summary list in the Wiki if I am thinking about building something new. This is the closest we have to a standard: http://www.cpcwiki.eu/index.php/I/O_Port_Summary

Bryce.

Edit: @Gryzor: you'll be pleased to know that ISO-6128 isn't actually used at the moment, so we could actually use this number

[MacDeath]

I vote for my Arduino mega protoboard to be the new extenson standard...

[rpalmer]

hello MacDeath,

I would say that my software HDOS has the capability to work from any storage device as long as the device driver exists to handle it.  This would make it perfect for any developer to interface it with other "custom" devices and hence allow for the beginning of setting a standard for storage handling.  The device driver interface is available to those who wish to create a custom driver for HDOS, so it is at least one step towards a common interface for storage devices.

The actual I/O address usage of the devices is not so important as long as the S/W is capable of handling the associated device types via a common driver interface standard that makes the I/O addresses irrelevant to the host software.  It is this method which makes HDOS better suited to a variety of storage devices than the custom software currently available.

The same methods can also be applied to Visual, Input and Audio devices. The only information of concern is the interface to the host software, which needs to be disclosed so that developers can apply the coding skills to match the common driver interface specification.

rpalmer

[Badstarr]

ISO6128! I like it! Even if a standard is only necessary for Mass Storage support it would seem to me like a good idea! I know it seems like Hard Disk Drives are a bit overkill when it comes to things like the HxC. However with the HxC (as fantastic as it is) there is not the flexibility of a Hard Disk, you have to predetermine what you would like access to and load the image into a slot then select it as the image in the drive. That's an amazing thing to be able to do with the CPC whichever way you slice it, its a major leap in convenience however not as transparent to the user as a Hard Disk.


I suppose that's kind of what I'm getting at is transparency, and if HDOS acts as a Hardware Abstraction Layer and hardware/software developers can hook into this to make a variety of HD solutions work. Games could be coded to sense the configuration and load massive files from a HD to have cinematic scenes etc. If the hardware is not present then this step is skipped and the game runs in standard mode.


As for other hardware, if something new and innovative comes along, say for example a co-processor system add on or whatever your imagination can dream up. If we had some way (and I know to an extent certain devices are must haves and are therefore standard to some extent) to say device "X" is now considered part of a standard CPC configuration then developers could make more use of them. I dunno, just off the top of my head, if a Megaflash was used to store graphics data in most of the ROMs for a piece of software, it could say on the "box" Minimum System Requirements: CPC 464, Recommended CPC6128 with Megaflash, with 4 slots free. That sort of thing 

[TFM]

The thought occurred to me today, after looking at some of the DIY hardware projects, specifically the IDE projects (I have always wanted a Hard Disk Drive for my CPC). Some of the threads on here associated with said projects point out that there are varying standards for hardware and software so I was wondering if maybe a group of hardware shooting stars on here could act as a sort of standards approval board?

Well, the guys making the software should be asked for this too. Or maybe even first :-) I always tried to convince people to stay compatible with existing hardware. However, only Bryce can be named here as a shining example of doing it right.
Pretty much all other people developp their own standard - which is ok, as long as if the hardware is something new (in a sense of "never connected to the CPC before").

I'm not exactly sure how it would work but maybe a CPCWiki seal of approval could be given if the hardware is designed to work with a particular driver or OS.

You already have something like this for FutureOS. It actually has the most comprehensive "compatibility list".

So a definite standard is decided on the software side and the hardware geniuses build to be compatible with it. I guess the users who bolt on extra modern hardware may not represent the average user, but when new software is written it could be assumed that a standard set of devices could be present and when it senses them it can use them.

I agree with you. So why not just stay compatible with existing software - as far as possible.

The other way of looking at it is, there are plenty of existing Hardware projects already on the wiki, so a poll could be made to decide on which ones are going to be considered the standard ones based on the usefulness and ease of build. Obviously, I wouldn't want creativity to be stifled!

A poll is always biased (since some people are lets say... in holidays)... Reality should be taken a "maker of the standard". And this is - at least to me - quiete obvious.

So as standard we shall use the following:

1. Amstrad
2. dk'tronics and Dobbertin (compatible and equal in many senses)
3. CPC-Booster
4. RAM7's 2 MB and Jareks 4 MB RAM expansion idea (same principle)
5. CPC-IDE/Symbiface2 and 8255IDE

We miss clear standards for:
- RTC
- USB

[Bryce]

Well there was a DKTronics RTC that was mapped to FBE0 - FBE2 as far as I can remember. But there were other less well known versions (Schneider International DIY RTC) that used different addresses.

As far as USB is concerned, my plan was to use the same address as some common RS232 expansion, that way it would work with existing comms software, just faster But RS232 mapping is a mess too I think? Aren't there many versions/addresses used for those too?

Bryce.

[TFM]

Well there was a DKTronics RTC that was mapped to FBE0 - FBE2 as far as I can remember. But there were other less well known versions (Schneider International DIY RTC) that used different addresses.

As far as USB is concerned, my plan was to use the same address as some common RS232 expansion, that way it would work with existing comms software, just faster But RS232 mapping is a mess too I think? Aren't there many versions/addresses used for those too?

Bryce.

In Germany the most popular and best sold was the Dobbertin Smart Watch, placed in a ROM card like a ROM. It's time was read like data from a ROM (also writing worked due to reading certain addresses).

For RS232 we had Amstrad, Schneider and CPC-Booster, which is still not that much. A couple of interfaces were there in addition - compatible to Amstrad - all that stuff recogniced by CP/M Plus :-)

[rpalmer]

For those still interested in the progress of my ethernet card, it is going well as I have managed to get a test mode into the S/W so that I can complete DHCP (and it is working as expected) and ARP.  The API for TCP/IP is comming along and its interface is along the IEEE standard, so existing understanding of the calls will make S/W ports possible.

If anyone wants to see what I have done so far just PM me for the complete S/W and documentation as it currently is.

It looks like it may soon come time to actually connect it to the real internet and attempt to do some real communication (lets hope all is goes well).

But apart from that I am using the same I/O addresses as that for the AMSTRAD RS-232 interface for the ethernet card, so we have in a way standardized the serial communication addressing. This has the only limitation of making the CPC with an ethernet card unable to also use a RS-232 at the same time.

Also, my TCP/IP implementation also has no driver inbuilt. So again a developer can build a custom driver for say booster or what ever and have a complete TCP/IP stack to test their drivers with.

In regards to HDOS as an abstraction layer, the only default drivers in it are the floppy and RAM discs, the rest are "loaded" by the user.  HDOS does have code in it to access a "virtual floppy" on the hard disc and I have created a patched AMSDOS version so that direct floppy disc access still get re-directed to HDOS.  I have yet to test this aspect as the ethernet card has been taking up all my time.  There is still one problem and that is when loaded S/W has its own floppy drivers, there is no way to get around it and so not all games can be run from a hard disc.  Also I have found that some games do not allow for extra roms to be attached and this too limits the running of S/W (this was to prevent some H/W additions to halt the CPC to allow for game copying).

rpalmer

[Gryzor]

What software are you going to use with it?

The first ping (www.cpcwiki? ) should be really exciting...

[Bryce]

I believe the first CPC Ping(-pong) was by Imagine, released in 1986. Since then we've only had Pang.

Bryce.

[rpalmer]

The first software to use the TCP/IP stack will be telnet as an external application using the APIs.

The original TCP/IP stack had finger, ping and telnet as an internal functions and there were no means to allow for external applications.

The original finger and ping functions will also be developed as external applications using the APIs.

The source for all of this will become freely available, so that others can develop their own applications.

I am also looking a creating a simple text only web browser along the same lines as Lynx.  However, the CPC version will only the simplest of HTML and have limited capabilities as compared with the latest browsers.  A good start would be the simple html that i use for the HDOS documentation.

rpalmer

[TFM]

But apart from that I am using the same I/O addresses as that for the AMSTRAD RS-232 interface for the ethernet card, so we have in a way standardized the serial communication addressing. This has the only limitation of making the CPC with an ethernet card unable to also use a RS-232 at the same time.

So... your Ethernet-card is compatible to an RS-232 Interface from Amstrad? Right?

[Bryce]

Do you intend making or having a batch of these made up? Where do you think the price would lie?

Bryce.

[rpalmer]

TFM/FS,

The ethernet card simply uses the same base I/O address as the RS-232 card. That is why the RS-232 interface cannot be used with the ethernet card.
As for the software, the use of the ethernet card cannot be used as a replacement for the RS-232 as they are different hardware entirely.

My TCP/IP stack has been developed so that the API which uses standard IEEE names and parameters will allow for ported applications. The application itself could in theory be used with the ethernet card or with some other interface where the driver exists to handle the data.

The full software driver for the ethernet card will be made available so that developers can see how the driver works independently of the TCP/IP stack to handle the data.  This separation of the TCP/IP stack from the driver allows for applications to not care what the device is.

rpalmer

[TFM]

The ethernet card simply uses the same base I/O address as the RS-232 card. That is why the RS-232 interface cannot be used with the ethernet card.
As for the software, the use of the ethernet card cannot be used as a replacement for the RS-232 as they are different hardware entirely.

Well, from the first peek at it, that makes sense. One would think, either an RS232 or an Ethernet-Adapter would be enough.

At the second look at it I think it's a pity to do it that way, because if you have one CPC as Ethernet computer (terminal), you could use the second one as data-source (mainframe). One CPC does the networking and the second one provides / saves the files, maybe using HDOS. So it would make sense to connect them using RS232.
I mean... there are so much unused ports on the CPC, why not use them? IIRC your Ethernet card has still prototype status, maybe you like to change these ports.

Else you can't talk about compatibility, in contrast then Ethernet and RS232 would be incompatible.

To help you out of the I/O problems, this may be of value for you:

http://cpcwiki.eu/index.php/I/O_Port_Summary

[rpalmer]

TFM/FS,

The use of both the RS-232 and the ethernet would make the CPC have virtually no functionality available for server S/W or anything else as the processing of each device would take up too much time.  Although I find some measure of agreement about using both together, but once people get use to the speed of the ethernet and given that many of the current devices for network communication are based on ethernet the use of a slow rs-232 might seem unlikely.

Here in aus, the dial-up modem usage is so low and that we are soon going to be forced with the NBN (Nat. BroadBand Network), dial-up we go the way of the dodo.

Also the use of a different I/O port (or ports) means there are more chips to the interface which makes it even more complex to design and to build. The PCB design package I use is free (but has a limit on the size of the board) so to add more chips is just to hard at this time.

It may be possible later on, to tweak the design (may be have a port select) for this but for now I can only do so much with what i have available.

rpalmer

[TFM]

Well, I thought about two CPCs. One uses the Ethernet card to get data from the network. And this first CPC is connected to a second one, it provides data to the second one using a RS232 interface. My idea was that the second one get's the data "prepared" for usage. It this concept makes any sense in reality seems to be checked in future.

However I think that RAM is the limitation in our case. If you work f.e. with an RS232 with 19.200 baud then you get already 144 KB in one minute. Ethernet is faster, but data needs to be processed (that brings us back to the Two-CPCs idea, one for data processing and the other one uses the processed / prepared data).


BTW: I like Dodos (even if I know them only from comics)
EDIT: CPC & Dodo: http://thefunkydodo.com/cpc-real-estate-solutions-ltd-2/

[rpalmer]

TFM/FS,

Lets not forget that for Ethernet there can be many CPCs connected in a local network via a hub/switch where as for the RS-232 only one other CPC can be connected. I have yet to know of a means of connecting multiple CPCs via RS-232 in a local network.  There was a means of connecting the CPCs in a network via the Virtual Net '96 but the device for this was via the printer port and the custom software was not available to check for suitability with TCP/IP.

The other thing about RS-232 is that this will be the limiting factor in the speed of the ethernet to handle its packets of data meaning that eventually there will packets lost due to full buffers on both the ethernet chip and in the CPC buffers as the slow RS-232 will block the ethernet data traffic.

Also to connect the RS-232 as well will still need some form of protocol to communicate (like SLIP/PPP) and this too will slow its rate.

You mention that the data in the ethernet needs to be processed, well i found that it does not need to be processed like SLIP/PPP as it is already encapsulated in the ethernet packet format.  The SLIP/PPP encapsulation protocol is there for RS-232 to know where a packet starts or ends and may have escaped bytes to ensure they dont get misinterpreted. This protocol is what slows down the RS-232 and the CPC, where as for the ethernet the data can go as is and thereby not impact on the CPC as much.

rpalmer

[TFM]

You point on some important points :-)

However, there must be a reliable buffer-overrun-protection. It's important that one device can tell the other device "stop sending" in case of a full buffer.

If software would have to care about buffer-overrun, then coding would be thought. And you couldn't do much more than to interchange data. I guess the Ethernet card is capable of buffering and "handshake"?

The VN96 network is very nice, easy to build and cheap (2 bucks?), but it's not the quickest solution. It may not be suitable at all for TCP/IP. But it has other advantages: http://www.reocities.com/SiliconValley/Park/6129/choose.htm

For a CPC network I would use the CPC-Booster with the RS485. But if the Ethernet card can be used to connect some CPCs to each other too, then GREAT!!! It is for sure the most quickest alternative IMHO. And it would be the logical choice.

[rpalmer]

Hi TFM/FS,

The ethernet chip itself does all the handshaking and buffering, so the CPC is left with just sending and getting packets of data.

I have implemented and cyclic buffer internally within the CPC to handle incoming and outgoing packets, since my implementation of the TCP/IP works independently of the device the user chooses to send/get data.
This design makes it the most portable implementation (and most likely a good standard) to allow for a variety of devices. The devices themselves only need to know where data is stored/accessed to send/receive packets.

The CPC-Booster sounds like it can send data quite quickly, but its connector is not even used here in aus as far as i know.

How popular is the RS-485 connector for networking in the EU? Are there converters for it to other types like ethernet?

rpalmer

[TFM]

That sounds very well!

Well, IMHO today 99% is done by Ethernet. So the RS458 is not so common. However I had no problems to get cables to set up a small CPC network at home in 2007.

Is there a way to change the ports of the card? The collision with Amstrads RS232 interface is a problem for people who have attached both devices.

Can software check which one of the devices is connected (Ethernet card or RS232 interface).