CPC-CPLINK - a coprocessor interface card for all CPCs

Started by revaldinho, 20:54, 10 November 19

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

revaldinho

#25
Quote from: shifters74 on 10:48, 25 November 19
No reason why you cant have auto boot as per biged's post if some one provides the code (will make it an option as i use an M4 for that).


I've checked in bigEd's bootstrap into the Github repo. It's in the /sw/examples/bootstrap/rpi_c folder. There is some assembler code there which needs to have the GNU project z80asm installed (it's available via apt-get from Linux), but otherwise installation is all as described in the Makefile.


Also on the MCP itself, I wrote a page of BASIC which I uploaded to the rep in /sw/examples/mcp/cpc_basic/mcpterm.asc. It's a very simple terminal which lets you type the MCP commands, so please give that a spin too. It would be nice if there were a 'HELP' command from the MCP, and bigEd and I wondered if unrecognized commands might just be sent straight to the Pi shell, making it possible to add other scripts or programs to extend the Pi services without necessarily editing the MCP code itself ?


R.

biged

Very interesting development shifters!

As for the one-line bootstrap, I might have a cunning plan...

I think if we arrange for the one-line boot's payload to send a string 'BOOT\n' before it starts to wait for a response, that might allow a degree of compatibility with your MCP.  And if the CPC-side front ends which talk to the MCP would drain the FIFO at startup, that might be even more compatible. They don't need to know the length of the payload, they just discard it. Then the Pi-side code can always start by pushing the payload, in case it's needed, but no harm done if it isn't. (It's well under 100 bytes, so barely any time passes. But it's more than 16, so a FIFO reset isn't enough.)


I'm thinking the code loaded by BOOT could be a menu-driven jukebox interface, mainly to select games or applications or ROM images, but also able to select the loading of an RSX which could add some useful extensions, perhaps a storage implementation so LOAD and CHAIN can work via the CPLink's Pi. (I'd like the one-liner to be able to load and start a Basic program, and for that I think we need CPLink to be able to look a bit like a tape, or maybe a block device.)


By way of illustration, in the land of Acorn, where I come from, there are two or three giant game collections with their respective jukebox front ends, for the various machines:





shifters74

#27
Hi Biged/Revaldinho

Actually I already have an injection mechanism on the pi side which is what i used for testing on the PC.  If you provide a z80 binary file - i can load that at MCP power up - inject into the out_queue ready for when the CPC connects e.g. via your basic which can then load and boot what ever you like!  I was thinking of an RSX that could be in memory or ROM (M4 or X-MEM i was thinking) for some of the basic commands in asm.  I will have to look into that side later as currently i am writing basic and C on the amstrad side as a means to working quickly!


I will make it a #define so you can include the boot injection in the build or not with a #define in mcp_pi.h

I like the chain idea!

I like the idea of a HELP command in MCP so will add one for version 0.2!!

I was planning on a pass-through of unknown commands to the PI but that requires direct support in the MCP (either via socket/pipe or file) and was something i wanted to do but not just yet (v0.4?).

I like the MCPTerm idea too - was coding C for testing but that will be quicker too especially for off the cuff tests


Keep the good ideas coming!

Any feedback on the MCP - don't be shy!!  Any build is a build and it all gets better!


As for the cunning plan - its so cunning you can brush your teeth with it  ;D

cheers

Shifters

GUNHED

Would it be possible to send code from the CPC to the Pi? Basically the CPC would initialize the Pi and take control over it. Can this be done?
http://futureos.de --> Get the revolutionary FutureOS (Update: 2022.03.09)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

biged

Certainly in principle the CPC could send down a binary or a script which the Pi can choose to run. When the Pi boots - and I'm tending to assume the Pi will boot first - it needs to, at minimum, start something which is ready to listen to the FIFO.

It might be that we end up with several mutually exclusive approaches, or it might be we can wrap all the interesting applications into one approach.  For any given approach, it's useful to think through how the protocol should work, and how it should cope if the other end isn't there, or isn't listening, or is expecting some different set of interactions, perhaps because it's a newer version than the other end.

But if the software on the Pi and the software on the CPC are both expecting each other and are speaking the same language, all should be well.

biged

Might be worth just listing some of the possible things a CPLink-connected Pi might be good for, with suitable software at both ends:

       
  • mass storage, acting as a tape or as a disk
  • paging memory contents in or out, as per shifters' MCP
  • providing a jukebox frontend to a collection of games, or utility ROMs
  • connection to a BBS (over telnet or web)
  • connecting the CPC's keyboard and screen to a Linux prompt on the Pi, or to an ssh connection elsewhere
  • connecting the Pi's keyboard and screen, or an ssh session, to the Basic interpreter or other application running on the CPC
  • downloading software from the web, as disk images or otherwise
  • connecting one CPLink-enabled machine to another one over the internet
  • making the Pi act as a second processor to run applications, perhaps Z80 applications running in emulation
  • forwarding street-legal text and graphics commands to the Pi's HDMI output
  • forwarding sound requests to the Pi's audio out, perhaps as high level MIDI or as low level SID register accesses
  • using the Pi as a real time clock
  • using the Pi as a computation server or FPU, to speed up fractals or other numeric work
  • using the Pi to run emulators of other machines, such as a Spectrum, and forward graphics up for the CPC to display (but limited in their update rate! Probably not going to run Elite this way.)
  • controlling or talking to any given USB device on the Pi
  • controlling or talking to any I2C or SPI connected device on the Pi, if the Pi has the spare pins for it
  • using one of the Pi's UARTs for serial comms, if the Pi has the spare pins
  • send teletext data to the Pi for inclusion in its composite output for display on a teletext TV
Basically almost anything a Pi can do, if stuffed through a 50kbyte/sec channel (I think), that makes sense.

shifters74

Quote from: biged on 19:50, 25 November 19
using one of the Pi's UARTs for serial comms, if the Pi has the spare pins

It can already do this - the UART link is on the interface  - Revaldinho uses it already!

shifters

shifters74

Quote from: biged on 19:50, 25 November 19
using the Pi as a real time clock

MCP does this providing you only want HH:MM (could add SS if you want it)

cheers

shifters

LambdaMikel

#33

Great progress on this project and nice ideas - from the long list, these would be my favorite things I would like to see:
Quote from: biged on 19:50, 25 November 19

       
  • paging memory contents in or out, as per shifters' MCP
  • connecting the CPC's keyboard and screen to a Linux prompt on the Pi, or to an ssh connection elsewhere
  • connecting one CPLink-enabled machine to another one over the internet
  • making the Pi act as a second processor to run applications, perhaps Z80 applications running in emulation
  • using the Pi as a computation server or FPU, to speed up fractals or other numeric work

Those would be the biggest sales arguments IMHO for CPC-CPLINK (the other potential use cases are to some extent already well covered by existing expansion cards)


EDIT - I'd also like to use the Pi as a "print server" for my CPC. I guess one would have to patch MC SEND PRINTER from the Machine Pack section and related jumpblock entries such that BASIC prints to #8 go to the CPC-CPLINK rather than the printer port... can the CPC-CPLINK patch the jumblocks as soon as the "start printer server" command is being issued on the Pi?

GUNHED

Quote from: shifters74 on 21:41, 25 November 19
MCP does this providing you only want HH:MM (could add SS if you want it)

cheers

shifters


Seconds would be necessary IMHO, else it's not really usable. If there will evolve some kind of 'standard' I'll support it with FutureOS. About anything else - depends on my free time.  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2022.03.09)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

shifters74

Quote from: GUNHED on 22:58, 26 November 19

Seconds would be necessary IMHO, else it's not really usable. If there will evolve some kind of 'standard' I'll support it with FutureOS. About anything else - depends on my free time.  :)

OK Added in the current dev build  :laugh:

Shifters

biged

Quote from: LambdaMikel on 19:19, 26 November 19
... use the Pi as a "print server" for my CPC...
Nice idea! I imagine that's not too hard, although I don't know the low level CPC-side things (yet) being rather new to the land of CPC.

For a CPC to make use of CPLink facilities, I think one of three things is needed:

       
  • a ROM installed which patches the right vectors at boot time
  • a program to run from disk which loads the necessary driver code and then does as the ROM would
  • a one-line Basic bootstrap which loads a payload which then loads a program as above

The middle one is probably easiest for development, assuming devs have a CPC and a solid state storage solution.  The first one might be best for end-users, but the middle one will do for most.  The third one is of most interest to me, as a way of getting a vanilla unexpanded CPC into the new world with the least amount of kit and money.

GUNHED

Quote from: shifters74 on 23:04, 26 November 19
OK Added in the current dev build  :laugh:

Shifters


Great! Thanks!  :)  Also SymbOS and CP/M Plus can benefit from this, because they use time stamps too.  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2022.03.09)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

shifters74

#38
Hi all,
i would like to run some ideas passed you with regards the protocol communication between the MCP and CPC.

Currently the protocol is:

    COMAND_NAME\n or COMMAND_NAME PARAM\n or COMMAND_NAME PARAM PARAM\n etc

When binary data is exchanged it just follows on from the \n and expects the CPC and MCP to know how much there is etc (which it should as it created/requested it!).


I am thinking of changing this with a mechanism to make this a bit more robust - so here goes:

    +++2byte_packet_size packet_type payload_of_data---

where +++ preceeds the start of a packet and --- terminates it

where 2byte packet_size is size of whole packet (but not +++ or --- which are really delimiters)

where packet_type is 1 - command text 2- binary 3- graphic commands etc

where payload is the text or binary data

where --- is the packet terminator


The purposed of the delimiters - when reading response from MCP on CPC - a command does not find +++ when it starts to read response from the MCP just skips what ever data it is until it finds a +++ and then starts reading the packet i.e. where there is data from the MCP not completely read by the previous command run.  Ditto on the MCP where for example CPC sends 1028 bytes of binary_data instead of 1024 bytes - the MCP read the 1024 bytes and processes it then comes to read the next command and finds rubbish - with this it throws away the 4 bytes until it finds the +++ to signify that its the start of a command.

e.g.

    + + + 08 00 01 P I N G \n - - -  (with no spaces of course)

    + + + 08 00 02 01 02 03 04 05 - - - (some binary data)

It means some significant changes to MCP protocol handling code and changes to the basic and c tools but maybe now is the best time to do so - so in future we dont break anything.

V0.2 is code and feature complete - just testing it but debating making these changes before releasing it.

Your thoughts?


cheers

Shifters

GUNHED

Quote from: shifters74 on 16:39, 27 November 19
It means some significant changes to MCP ... snip...


Do you have any CLU if we need a TRON program... just in case...  ;D
http://futureos.de --> Get the revolutionary FutureOS (Update: 2022.03.09)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

shifters74

Quote from: GUNHED on 17:14, 27 November 19

Do you have any CLU if we need a TRON program... just in case...  ;D
Maybe some future commands for debugging (TRON/TROFF)  :laugh:

Shiftres

LambdaMikel

... also, I am still dreaming of using my CPC for email... preferably from BASIC with a couple of RSX commands.



END OF LINE

biged

I'm not quite sure about your proposed protocol enhancements, @shifters74 so I think I'd suggest releasing your 0.2 and then continuing the discussion...

About the idea of a length for each message, I like that.

About the preamble for resync, I'm not sure - maybe!  It feels like it might be a route for making things more complicated (with recovery tactics) and the end result might be unreliable interoperation instead of things not working. Things not working can be easier to debug!

I think I'd suggest some exchange of version numbers: perhaps if the CPC sends a HELLO and the Pi responds with a WELCOME, those can come with version numbers, and we just say they have to match.  I'm not sure about this.

About the trailing post-amble, I'm even more not sure about that.  I suppose if you have a length, and a preamble, and a postamble, you can read an entire packet and validate it, and reject it if it doesn't fit the facts.  But it would be slightly more robust to end with a CRC or checksum.

One observation about the preamble and postamble - these are byte sequences which could occur inside data packets.  Although it's possible to escape special bytes over the wire, that's a level of complexity we might not need, and it would hurt throughput.

I'm sure you're right to anticipate some data exchanges being binary and some being text.  I'm not sure if they need to be marked though - can we assume the requester knows what the response should look like?

Have you any thoughts about multiple users of the channel?  If one person develops a MIDI channel idea and another person develops a printer buffer idea, do we expect them to interoperate, or to interleave, or to setup and tear down the connection for each user?  I'm vaguely thinking about tagged commands and responses, so things can interleave. But it feels like a very ad-hoc way to design a protocol!  I think maybe drawing out some typical expected cases will be worthwhile.  And accepting that we'll make more than half a dozen revisions before we converge on something which is no longer changing.

Because I come from the land of Acorn, I'm fairly familiar with the Tube connection between a host and a second processor.  In Acorn's original implementation, that's four FIFOs in each direction, with some defined conventions about how they are used (something like this: VDU/keyboard; events and interrupts; file system control channel; block transfer data channel.)  But whatever they did, subsequently there was an implementation of Tube over a serial connection - just one channel in each direction, and some low layer of the protocol to say what each packet was.  I'd be inclined to look into that, at least to learn from it.

zhulien

I am wondering if I should adapt this to use the PI for tasking instead of the CPC - what do you think?  Maybe a better programmer than me wants to continue what i started to make a hopefully better MCP?


http://www.cpcwiki.eu/forum/programming/interrupts-questions/msg164115/

shifters74

Quote from: LambdaMikel on 21:59, 27 November 19
... also, I am still dreaming of using my CPC for email... preferably from BASIC with a couple of RSX commands.



END OF LINE

Online service e.g. IRC, telnet, bbs, wget etc is something i started the project for but will add email to the list also!!

regards

Tom

shifters74

Hi Biged,

the protocol overhead is only 9 bytes and the mechanism is structured to be extendable and has already (sorry i just spent 2 days implementing it for v0.2!) make the MCP code more robust, clearer and cleaner in implementation.

I think the CRC is a good idea but 0.2 has so much in it already and needs so much testing that i think i draw the line at implementing that for this version (TRON and TROFF will go in which switch the extended output debugging on and off!).

Any other TRON references we can build in  :P

cheers

Tom

biged

Fair enough Tom. Tracing could prove to be very useful. And if the MCP code has got clearer as a consequence, that's a win too.

I did have another thought: if packets are no more than say 256 bytes of payload, then we never have to wait too long for the end of a packet. That helps if say the user wants to interrupt something or if two services are both active and are interleaving packets. It might make it easier to resynchronise.  And it means the payload length can be a single byte.

I'm not at all sure whether it's better for say a 16k transfer to be a single indivisible flow or if it would be useful to acknowledge each packet.  I wouldn't want to reinvent ZMODEM or SLIP or PPP. But maybe we can learn something from those.

@zhulien yes, I see no reason why tasks can't be swapped out and swapped in using the Pi. Just so long as 50kBytes/sec is fast enough to be useful for this case.

shifters74

Hi Biged,

the payload can be 1 byte to 32K bytes per message - we are not on analogue modems no slip/ppp required!

shifters

LambdaMikel

Quote from: zhulien on 02:11, 28 November 19
I am wondering if I should adapt this to use the PI for tasking instead of the CPC - what do you think?  Maybe a better programmer than me wants to continue what i started to make a hopefully better MCP?


http://www.cpcwiki.eu/forum/programming/interrupts-questions/msg164115/
Oh, yours was also called MCP? Maybe you guys can merge the projects? I guess @zhulien was first in the use of the epic cinematic name  8)

zhulien

I hope someone else likes the idea of a uniform method of creating AMSDOS drivers / background tasks - or even perhaps ROMS where users can select the 'content' of the driver ROMS and it dynamically builds the ROMS - that is how I created the 2 CP/M Accessory ROMS (Dragonbreed + Other).  Although CP/M ROMs are easier because they don't actually run from ROM, but the principles can still be the same, eg. I have M4, choose M4 support, I have Playcity, choose Playcity support, then the ROM is built up with the custom selection of drivers.  Even such things as speech, with proper but not over-complicated API, such as allocate-speech, speak, deallocate-speech (so that multiple concurrent tasks can run and not conflict.  RAM these days is not an issue and we have so much cool hardware that mostly doesn't work together (from a software point of view) - CPC BASIC has fantastic RSX and ROM support so it really isn't an excuse for everyone to not care.  Symbos is the exception and very remarkable in every way - but... for the time being it is still an alternate OS.

Powered by SMFPacks Menu Editor Mod