Author Topic: CPC-CPLINK - a coprocessor interface card for all CPCs  (Read 2506 times)

0 Members and 1 Guest are viewing this topic.

Offline GUNHED

  • 6128 Plus
  • ******
  • Posts: 1.394
  • Country: de
  • Reincarnation of TFM
    • FutureOS - The quickest OS for the CPC and Plus
  • Liked: 793
  • Likes Given: 1668
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #50 on: 15:37, 29 November 19 »
Honestly - I guess it's very important to have things uniform and having some kind of 'standard', because then everything is way more easy for everybody. Of course we still can all reinvent the wheel again - but please with the same protocols (or what else is needed).  :)
http://futureos.de --> Get the revolutionary FutureOS (Recent update: 2019.08.07)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2019.08.14)

Offline shifters74

  • CPC464
  • **
  • Posts: 47
  • Country: gb
  • Liked: 35
  • Likes Given: 13
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #51 on: 19:16, 29 November 19 »
Hi all,
I have just reread some of the recent posts in more detail cos i been so busy coding i have not been fully reading  :doh:

Once i get v0.2 of MCP testing complete and released i have ideas about 0.3 but also open to suggestions about what people want next.  I think further discussion with biged's boot injection stuff and possibly zhulien's ideas is required!  I am not sure what some of what you are talking about with regard to standard driver support etc is (maybe revaldinho does ??) but would like to understand.  I am a lot more knowledgeable on the pi side than the CPC (though making progress!!) so happy to concentrate my skills there and work with others more knowledgeable doing the CPC side.

V0.2 of MCP is feature and code complete (yes really this time  :P ) and just testing remains given the complexity of the changes i have made for this release.  However testing is going well and I hope to release the code in the next week.

cheers

Shifters

Offline biged

  • CPC464
  • **
  • Posts: 10
  • Country: gb
  • Liked: 15
  • Likes Given: 12
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #52 on: 14:46, 30 November 19 »
Ah, I'm very new to CPC too!  I do have some thoughts, but I need to write them down carefully and I can't quite do that yet. Watch this space!

But I do notice a number of relevant concerns coming up in this previous thread, about using a serial connection for filesystem access
(Notably, @ikonsgr and @Docent discussing.)

(What we have in the CPLINK is very like a fast reliable serial connection, but also with control of the software and hardware at the far end: usually a Pi, but possibly a Teensy or Arduino or other.  A Pi is the favourite case for my purposes, as it's high performance, can run a full Linux, and has some useful peripherals built in.)
« Last Edit: 14:57, 30 November 19 by biged »

Offline zhulien

  • 464 Plus
  • *****
  • Posts: 434
  • Country: au
    • 8bitology
  • Liked: 195
  • Likes Given: 121
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #53 on: 00:48, 02 December 19 »
Who here is open to talk in google hangouts?  We can make a group for MCP development & drivers - sometimes brainstorming is easier interactively.


I did actually start some driver work for CPC a while back but i think things can be improved and if there are input from multiple people who made the hardware - that can also be invaluable.


note: I cannot publish the google sheet into this forum for some reason, not sure why. if you want access before it goes into a wiki or git... let me know your gmail.
« Last Edit: 03:35, 03 December 19 by zhulien »

Offline revaldinho

  • Supporter
  • CPC664
  • *
  • Posts: 80
  • Country: gb
  • Liked: 142
  • Likes Given: 79
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #54 on: 20:38, 02 December 19 »
@zhulien , I can't see the Google Sheet in the Forum post, it just says




Google logoWe're sorry. This document is not published.

Offline zhulien

  • 464 Plus
  • *****
  • Posts: 434
  • Country: au
    • 8bitology
  • Liked: 195
  • Likes Given: 121
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #55 on: 12:02, 03 December 19 »
I have started a Google hangouts group too for chat - this is likely short term, I wonder if a realtime chat could be added to CPC Wiki or whether an IRC forum exists?  But... hangouts is ok - it keeps our chat history to some degree too.


Msg me if you want to join the hangouts group also with your gmail.

Offline Bryce

  • The Hardware Guy.
  • Supporter
  • 6128 Plus
  • *
  • Posts: 11.099
  • Country: wf
  • It's not broken, it just hasn't been fixed yet.
    • index.php?action=treasury
  • Liked: 3931
  • Likes Given: 410
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #56 on: 12:07, 03 December 19 »
The Forum did have a chat function for a while, but it was removed later. Probably due to no-one using it.

Bryce.

Offline zhulien

  • 464 Plus
  • *****
  • Posts: 434
  • Country: au
    • 8bitology
  • Liked: 195
  • Likes Given: 121
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #57 on: 12:49, 03 December 19 »
The Forum did have a chat function for a while, but it was removed later. Probably due to no-one using it.

Bryce.


Do you know if it had persistent channels like IRC?  or Just a temporary peer to peer chat while the session exists?

Offline Bryce

  • The Hardware Guy.
  • Supporter
  • 6128 Plus
  • *
  • Posts: 11.099
  • Country: wf
  • It's not broken, it just hasn't been fixed yet.
    • index.php?action=treasury
  • Liked: 3931
  • Likes Given: 410
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #58 on: 13:30, 03 December 19 »
I think it was just temporary, but you'd have to ask @Gryzor .

Bryce.

Offline Gryzor

  • Administrator
  • 6128 Plus
  • *****
  • Posts: 15.176
  • Country: gr
  • CPC-Wiki maintainer
    • CPCWiki
  • Liked: 3009
  • Likes Given: 5345
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #59 on: 17:22, 03 December 19 »
At one time we had IRC, then a local chat. Not many people used it and I removed it due to the resources it required...

Offline zhulien

  • 464 Plus
  • *****
  • Posts: 434
  • Country: au
    • 8bitology
  • Liked: 195
  • Likes Given: 121
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #60 on: 03:10, 04 December 19 »
Rather than me hi-jacking this thread, I will create another non-hardware specific Driver thread. 

Offline GUNHED

  • 6128 Plus
  • ******
  • Posts: 1.394
  • Country: de
  • Reincarnation of TFM
    • FutureOS - The quickest OS for the CPC and Plus
  • Liked: 793
  • Likes Given: 1668
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #61 on: 20:32, 04 December 19 »
Needs to be split into 3-4 parts please.
http://futureos.de --> Get the revolutionary FutureOS (Recent update: 2019.08.07)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2019.08.14)

Offline biged

  • CPC464
  • **
  • Posts: 10
  • Country: gb
  • Liked: 15
  • Likes Given: 12
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #62 on: 18:00, 05 December 19 »
However testing is going well and I hope to release the code in the next week.


Hope things are still going well.  I said I'd try to write some thoughts down - here goes.


I think I've been approaching CPLink in a bottom up way: how to move bytes, how to get started with software both ends.  And I think MCP is a kind of top down way: how to provide a CLI, how to return printable results to requests that can be typed.


I'd like to arrange that the communication is reliable, and then rely on it, so there's no need for error detection and recovery. This is not a long-distance network, this is just a couple of FIFOs.


In the absence of MCP, I think the way I would have progressed is as follows:
  • define the format of a packet
  • define some standard types of packet
  • allow some room for expansion
  • start to provide some useful facilities at the packet level
  • implement a command line interface to those packets


So, for example, if packet types are a single byte, then I might have started with
  • 00 is a ping packet perhaps with a welcome message as the return
  • 01 is a packet going out of standard output, like to a printer or terminal emulator
  • 02 is a request to read data, it's standard input, like from a keyboard or a terminal emulator
  • 03 to open a file
  • 04 to read a block of data
  • 05 to close the file
and so on.  That's only a sketch of course.  It doesn't include any knowledge of CPC conventions, like for example the multiple streams feature of the VDU subsystem. Maybe byte FF would be an expansion, so the next two bytes are a longer type code, so we have lots of room for further facilities.


It seems possible that various facilities might be use at the same time: one might play a MIDI tune at the same time as spooling output to a printer.  For this reason I might well have said that packets should have a limited length.  Then packets can be interleaved without having to wait too long.


I think packets should always state their length. That means a whole packet can be skipped if it can't be understood - it's got an unknown type byte - or if there's no handler for it, or if it needs to be forwarded without understanding to a handler.


With this view, packet contents will sometimes be printable ASCII, but you never expect to type a packet as such.  A shell such as the present MCP client would pack data into packets and unpack responses from packets.  The present MCP server likewise would handle whole packets, and would have a tactic for dealing with packets of unknown type.


It might well still make sense for a server to be able to answer a query about which packet types it understands.  And it would certainly make sense for a CLI shell to have a HELP command which lists and maybe describes the verbs it is able to handle.


Now, possibly, just possibly, one could mix the bottom-up picture above with the present MCP picture, by having the type byte as the first byte, and any packet starting with a '+' byte is treated as newline-delimited text, or '---'-delimited text.  Or, if we can dispense with the +++ and --- because we've gained confidence that the communication channel is reliable, we can say any type byte which is alphanumeric is the first byte of a new-line delimited text.


But I'm not sure I like mixing the levels like this...  in the absence of any input from wise CPC experts, I'd probably use Acorn's Tube protocol as a model, and possibly the serialised version of that protocol.


Any thoughts?

Offline shifters74

  • CPC464
  • **
  • Posts: 47
  • Country: gb
  • Liked: 35
  • Likes Given: 13
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #63 on: 18:54, 05 December 19 »
Hi Biged,
a lot of what you have discussed is exactly what MCP v0.2 does currently including the packets.

V0.2 is finished and with Revaldinho for a last bits (makefiles etc) before it gets merged into his repo.  Once merged into his repo I will drop the release notes here.  The code is worth a read through (well commented!) as i think we are not too far apart in what we are trying to do.  The protocol used in 0.2 is flexible, extendable with just a few #define changes.  See the mcp_pi main loop which handles different packet types (text version of commands, binary version of commands, etc).  I implemented it with expansion in mind!


I am currently working on v0.3 which will provide:
1) binary equivalents of the text memory commands included in v0.2
2) GetFile and PutFIle from PI storage to CPC storage and visa versa
3) GetMemFile and PutMemFile from pi storage to cpc memory
4) other ideas in the pipeline but not set in stone including RSX commands, CPC file viewer etc
5) SEXEC which executes a shell command on the pi and returns results to cpccheers

shifters
« Last Edit: Yesterday at 10:33 by shifters74 »

Offline shifters74

  • CPC464
  • **
  • Posts: 47
  • Country: gb
  • Liked: 35
  • Likes Given: 13
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #64 on: 19:13, 05 December 19 »
Hi Biged,
one of things i have factored into the v0.2 design is that some commands you will type e.g. PING, HELP etc.  Other commands e.g. the memory commands you can but mostly will not hence why there are binary versions of them (destined for v0.3) i.e. the difference between a user typed command and an API  - the TextCommand is a user typed command (but can be done in code - see the basic and c commands included with MCP!)  - the BinaryCommand is an api call expected to be binary etc.

There are other packet types defined in v0.2 including BinaryData (for moving memory around etc) etc - see mcp_pi.h for the different type examples when 0.2 is published.

I have added a Version command just for you so it will tell what MCP your command is talking too!

cheers

shifters
« Last Edit: 19:30, 05 December 19 by shifters74 »

Offline shifters74

  • CPC464
  • **
  • Posts: 47
  • Country: gb
  • Liked: 35
  • Likes Given: 13
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #65 on: 19:21, 05 December 19 »

It seems possible that various facilities might be use at the same time: one might play a MIDI tune at the same time as spooling output to a printer.  For this reason I might well have said that packets should have a limited length.  Then packets can be interleaved without having to wait too long.

You can do this in concept in v0.2 as it provides command interleaving i.e. you can have commands that execute in steps so can have several things happening at the same time if you write the commands correctly (to support the interleaving). The SHUTDOWN and REBOOT commands both execute in multiple steps. 

Now, possibly, just possibly, one could mix the bottom-up picture above with the present MCP picture, by having the type byte as the first byte, and any packet starting with a '+' byte is treated as newline-delimited text, or '---'-delimited text.  Or, if we can dispense with the +++ and --- because we've gained confidence that the communication channel is reliable, we can say any type byte which is alphanumeric is the first byte of a new-line delimited text.

The reason for the delimiters is that i wrote the MCP and a number of basic and c commands but what is executing on the CPC will not always be in my control hence the need for delimiters when you get sent duff data to the MCP.  As its an overhead of 6 bytes its no big deal but its main purpose is to stop the command processor on the MCP grinding to a halt as it has no idea what it looking at because of the duff data its been sent.  I admit the +++ and --- is not fool proof but its a start!

shifters

Offline shifters74

  • CPC464
  • **
  • Posts: 47
  • Country: gb
  • Liked: 35
  • Likes Given: 13
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #66 on: Yesterday at 10:32 »
Please see http://www.cpcwiki.eu/forum/programming/cpc-drivers/  for zhulien's thoughtful look at developing a driver standard.




Offline shifters74

  • CPC464
  • **
  • Posts: 47
  • Country: gb
  • Liked: 35
  • Likes Given: 13
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #67 on: Yesterday at 13:11 »
Released MCP_pi v0.2 (wath associated CPC basic and c compiled commands) and merged in Revaldinho's repo (thanks!)
See attached release notes.
shifters

Offline revaldinho

  • Supporter
  • CPC664
  • *
  • Posts: 80
  • Country: gb
  • Liked: 142
  • Likes Given: 79
Re: CPC-CPLINK - a coprocessor interface card for all CPCs
« Reply #68 on: Yesterday at 19:29 »
Released MCP_pi v0.2 (wath associated CPC basic and c compiled commands) and merged in Revaldinho's repo (thanks!)
See attached release notes.
shifters

Making great progress on the MCP, @shifters74 - thanks for supporting this hardware project.


For anyone else interested, I have a couple of boards left from the first batch, already assembled and available now. There will be a slight delay 'til after xmas for further cards, as 74HCT40105s seem out of stock and are on back-order at Mouser and digi-Key in the UK (no worries, these are still active parts). I will need new PCBs at some point too and there's a ~3 week lead time for those.