Time to announce availability of a new CPC project: CPC-CPlink (pronounced CPC Ker-plink)
It's a card which allows you to connect an external co-processor, like a RaspberryPi or Arduino, directly to any CPC.
The card provides a parallel FIFO link in both directions through which data transfer rates of over 100K Bytes/s can be achieved.
CPC-CPlink's FIFOs and logic deal with all the critical signal timing, so there are no strict real-time requirements for the co-processor. A RaspberryPi running a full Raspbian (Linux) distribution is a suitable co-processor candidate, perhaps making available some of its hardware and OS services to the CPC. For example it's possible for the Pi to provide mass-storage SD card access, timers, serial ports or networking facilities to the CPC without having to write any bare-metal code on the co-processor. Acceleration is an interesting avenue to explore too.
The FIFOs present a status and a data register in the CPC's IO Port address space, and a bi-directional byte wide data bus and handful of control signals and flags to be connected up to coprocessor GPIOs. The programming protocol is very simple and is described in the documentation and by example programs provided to run on CPC and coprocessor implementing a simple loopback test. These demonstrate communications between a Raspberry Pi (using Python or C) and a CPC using BASIC, BCPL or C and libraries written in Z80 assembler.
Electrically, the card can interface to a wide range of co-processors using either 5V or 3V3 signalling. Since the most likely coprocessor candidate is a Raspberry Pi, the connector on the rear allows a Pi Zero to plug straight in and be powered from the CPC via the FIFO card. This makes for a very neat installation, but larger Pis and all kinds of Arduino, Teensy, PIC or other micros can be accommodated by a suitable cable adapter. On the CPC side, the card has a 50W right-angled box connector compatible with all popular expansion boards.
Just like the Old School 6128 RAM card (https://github.com/revaldinho/cpc_ram_expansion/wiki/'Old-School'-CPC6128-512K-RAM-Expansion-Card), CPC-CPlink is cheap and easy to build. All logic ICs are easy to source and easy to solder, through-hole 74 series components; there are no programmable parts of any kind. The project is fully open sourced and licensed under the GNU GPL3. All source code including Eagle board files, Gerbers and digital logic netlists are included in the GitHub repository (https://github.com/revaldinho/cpc-cplink/wiki) together with the software examples.
The V1.0 board has been built and tested using a RaspberryPi Zero co-processor, and is now ready for release.
For hardware DIYers, blank PCBs are available directly from SeeedStudio (https://www.seeedstudio.com/CPC-CPLINK-a-co-processor-interface-card-for-the-Amstrad-CPC-range-of-computers-g-1258738) and a reference bill of materials is available at Digi-Key (https://www.digikey.co.uk/short/pnv7fc); full construction details are provided on the GitHub Wiki (https://github.com/revaldinho/cpc-cplink/wiki). If you don't want to order packs of 10 PCBs from Seeed then you can get individual PCBs from me. I can also provide fully assembled cards for anyone who is more interested in the software side of things and doesn't fancy the soldering themselves. If you'd like to take up either of these offers then please PM me via the forum.
Sounds interesting, hope someone provides a complete assembly!
What uses do you envision for it? Reminds me of the CosmosEX for the Atari ST, which was highly interesting and useful!
Quote from: Gryzor on 20:12, 10 November 19
Sounds interesting, hope someone provides a complete assembly!
What uses do you envision for it? Reminds me of the CosmosEX for the Atari ST, which was nightly interesting and useful!
Thanks, and that's a good question.
In fact, I'm more interested to see what
you are planning to do with it ! :D That's why it's all open-source and designed to be very cheap and easy to build.
I should to stress that this isn't a project dedicated solely to the RaspberyPi, as any co-processor can be attached and you can do quite a bit with things like the latest Teensy4.0 too. However a RPi is the obvious candidate given its cost and capabilities. With the FIFO freeing up the co-processor from having to deal with any timing critical GPIO handling, you can program the Pi in any high level language and use it to provide some of its own OS and hardware facilities to the CPC. A PiZero W costs under £10 in the UK, so even if you just use it to provide the CPC with a real-time clock it's about as cheap as any other hardware solution. The Pi offers so much more than that though.
I need to work on the documentation and example code a bit in the short term. I'll show an accelerated Mandelbrot plot for example, with the CPC calling a Pi to do the time-consuming inner loop. I'll also look at making a better BASIC example with some RSXes for the FIFO handling. Probably I'm going to use the board to play around with other multi-processing ideas and run emulations of various CPUs on a Pi, but retro-computing possibilities abound here. It's a very open-ended project.
For non-DIYers, I am happy to make up small numbers of boards to order. These will be £26 + P&P - PM me if you'd like one.
A few ideas i am interested to try:
1) use pi as page memory i.e. can page 8 or 16K chunks in and out of CPC address space (C64 has something similar)
2) use pi HDMI screen as driven output i.e. commands in basic/asm to output to the pi screen rather than cpc's for hires graphics etc
3) interface to online servces via pi and wifi but use cpc keyboard and screen e.g. irc/telnet bbs etc
4) would like to see a fast 6502 and z80 on the pi so that you can send code to pi to execute under the emulator of that processor (like a bbc with a second processor with file, keyboard and screen access still to cpc).
Not all of these i will be able to do myself but very interested to experiment with it!
Does a Pi3A fit ok on the back or does it need a ribbon cable instead? Currently they are 17.89 on ebay!
cheers
shifters
Forgot to ask; will an M4 from Duke coexist with the board in an MX4 expansion?
thanks
Shifters
Quote from: shifters74 on 17:33, 11 November 19
Forgot to ask; will an M4 from Duke coexist with the board in an MX4 expansion?
Yes. I am using an M4 for development at the mo', using the wi-fi to squirt files to and from a Mac and as a mass-storage for the CPC. No problems. It's a great setup.
Some good ideas in your other post -
Quote
1) use pi as page memory i.e. can page 8 or 16K chunks in and out of CPC address space (C64 has something similar)
I guess you do know that the CPC already has an extended memory scheme which deals in 16K pages. The FIFO card won't let you use the Pi as an extended RAM using that particular scheme which 6128 software, FutureOS and SymbOS all rely on. You would need to use one of the many available RAM cards for that. You can create your own CPC software, with the Pi providing additional indirectly accessed RAM to swap in and out though. That's an interesting avenue to explore.
Quote
2) use pi HDMI screen as driven output i.e. commands in basic/asm to output to the pi screen rather than cpc's for hires graphics etc
3) interface to online servces via pi and wifi but use cpc keyboard and screen e.g. irc/telnet bbs etc
4) would like to see a fast 6502 and z80 on the pi so that you can send code to pi to execute under the emulator of that processor (like a bbc with a second processor with file, keyboard and screen access still to cpc).
These all sound very doable - and exactly the kind of thing I hope the card will enable. I'll look forward to seeing any of these getting demoed.
On the last one, CPC-CPlink is very much like a 'poor man's Tube' in the Acorn World. If you want to use an actual Acorn 2nd processor box or PiTubeDirect directly, then my other Z80 Tube project already enables that ... but is a bit light on all the host software required currently. See this older thread - http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/z80tube-running-acorn-co-processors-on-the-amstrad-cpc/ . I will get back to that at some point, but will mainly be working on this card for a bit.
Quote
Does a Pi3A fit ok on the back or does it need a ribbon cable instead? Currently they are 17.89 on ebay!
Good question and unfortunately I don't have a Pi3A to test this, but I think I'm going to recommend the ribbon cable. You did suggest wanting to use the HDMI output from the Pi, and even if the Pi3A fits when plugged in directly (I think it will as far as the height of the card is concened) you would not be able to access the HDMI port since it would be too close to your expansion board PCB.
I do have a Pi3B (full size) somewhere. I'll see if that plugs in directly and post some snaps later.
Very nice project...
Can we connect a eZ80?
Can the card issue interrupts? Can it send NMI requests?
In which way can the card access the CPC?
Look at the source code on github - the C source for the amstrad side is cross compiled with SDCC? Just run 'make' on it?
While not a z80 whiz i have been using c since turbo C days (and recently on arduinos extensively!) so would probably use your c code as a starting point for a project if thats ok?
Paging memory to the pi was to be for my programs - i do have an old school memory expansion for 6128 (and xmem too from toto). The c64 used to page memory in and out of main program space for its memory expander. I know this is not generally usable for other stuff until others use the same code - but the pi4 has up to 4GB of memory!! Again sharing resources as per your suggestion!
Do you have any source for the ribbon cables?
shifters
Quote from: shifters74 on 19:06, 11 November 19
Do you have any source for the ribbon cables?
I haven't got any specific source for them, but a short version of this kind of thing would be fine
https://www.ebay.co.uk/itm/GPIO-Extender-Ribbon-Cable-40-Way-MALE-FEMALE-for-Raspberry-Pi-Model-B-UK-IDC/143182757268?hash=item21565b7d94:m:maH1EOAT9-UTvgc1SuHmTNw
However, I have just plugged my Pi3B in and ... it very nearly fits. In fact it does fit but won't complete mate squarely because the ethernet connector box very slightly overlaps the FIFO board so I can't push the connector all the way in. It fits well enough for me to boot the pi and run the loopback tests though, powering the Pi from the FIFO card. (I'm using an external supply for the expansion card and I can see 0.5A being consumed by the Pi + FIFO + M4 + ROM + Old School RAM card.)
So, looking at the Pi3A+ I think that will fit nicely and there's more clearance below the card than I thought there would be. You might need a flexible right angle type miniHDMI adapter, but certainly looks possible that you can get at the HDMI with a Pi3A+ mounted on the back.
On the libraries and examples, yes please help yourself - that's what they are for and they better describe the interface than any amount of text. :D
Here are a couple of snaps showing the Pi3B plugged right in.
Quote from: GUNHED on 19:01, 11 November 19
Very nice project...
Can we connect a eZ80?
Can the card issue interrupts? Can it send NMI requests?
In which way can the card access the CPC?
Thanks, Gunhed.
If an eZ80 has a parallel port you can use to connect to the data bus and handshaking lines, then yes you can plug that in with a cable adapter.
The card doesn't connect to the INT or NMI lines. My original prototype using a CPLD has those lines connected, but I didn't implement any functionality there and chose to leave it out of the all 74 series version mainly so that it would all fit in a small number of ICs on an 80x100mm board, which is the limit of the free-Eagle CAD tool.
So, access on both sides of the FIFO is by polling the status flags - which are just FIFO data in available, FIFO data out ready.
Ok, thanks a lot for your answer. That could be a great thing more a kind of "math co processor" for example. But lot's of other things are thinkable. Has the card some "connection" to the outer world? Probably that's not needed, but I'm curious. :)
Quote from: GUNHED on 20:39, 11 November 19
Ok, thanks a lot for your answer. That could be a great thing more a kind of "math co processor" for example. But lot's of other things are thinkable. Has the card some "connection" to the outer world? Probably that's not needed, but I'm curious. :)
Not really. The card brings the UART pins from a Pi or Arduino/ChipKit/Teensy out to pins on the front. This works well to allow comms from another PC/Mac direct to the co-processor when the co-pro is running headless. (On the Pi you just need to enable the serial login via raspi-config when you setup initially). Otherwise I'm relying on you using the IOs direct from the copro - with the Pi3B plugged in you have ethernet, multiple USB, audio, HDMI and even WiFi. They are all accessible. If you use a stackable connector on the co-pro then you can still get at the other GPIOs which aren't required for the FIFO interface too.
Just going back to the Pi3B for a moment, I think that if you use something like this
D7XTC3KTDOLong tall 40 20x2 pin header stacking extension, 2.54mm pitch for Raspberry Pi (https://www.ebay.co.uk/itm/Long-tall-40-20x2-pin-header-stacking-extension-2-54mm-pitch-for-Raspberry-Pi/193060049594?hash=item2cf34692ba:g:yuMAAOSw9ytdXVa-)
as a spacer, then that will solve the issue of any tall components on large RPis and let them all mount directly into the card. It looks like the Zero and Pi3A+ will fit perfectly, but Pi3 and Pi4 will need extra clearance, or a short ribbon cable.
If anyone wants to fit a tall socket on the FIFO card to start with, then something similar to this looks like a reasonable option
2KF5HNMS9XRRaspberry Pi GPIO Tall Header - 2x20 (https://www.ebay.co.uk/itm/Raspberry-Pi-GPIO-Tall-Header-2x20/142615441658?epid=15010897809&hash=item21348af0fa:g:OzEAAOSwa81aJs2I)
Pimoroni also sell the stacking headers - you can use them with a Pi4 to stack the cooling fan with other hats for example.
shifters
Quote from: shifters74 on 22:11, 11 November 19
Pimoroni also sell the stacking headers - you can use them with a Pi4 to stack the cooling fan with other hats for example.
Thanks for that pointer. Looks like one of these will do as a spacer, so no need for a ribbon cable after all.
https://shop.pimoroni.com/products/booster-header (https://shop.pimoroni.com/products/booster-header)
I think the following ideas are most useful when I get the time...
Modify a terminal app to communicate to a pi and have the pi direct i/o to the cpc. Allow for pi hosted small c for example to build directly to cpc.
Write a graphics protocol that ideally is RTG for cpc to write to native or hdmi and the terminal should support this.
I think one of the first things to write is a shutdown command to run on the cpc that can tell the pi to safely shutdown! :D
I think writing routines to do the functions that load into an M4 rom slot (or xmem rom slot) would be most useful to share code across any tools - any one any experience in doing that (or documentation) to help out with standard rom layout etc?
Thoughts?
Think its time to brush up on z80 assembly! :-[ Chibi Akumas videos here i come!! :P
shifters
Just a brief update after a bit of a plug-fest with different Raspberry Pi Models
RaspberryPi Zero and Pi3A+ both fit perfectly on the standard connector.
For full-size Pis, which have more high-rise components on board, I tried cards using both of these taller GPIO connector options
- 2KF5HNMS9XRRaspberry Pi GPIO Tall Header - 2x20 (https://www.ebay.co.uk/itm/Raspberry-Pi-GPIO-Tall-Header-2x20/142615441658?epid=15010897809&hash=item21348af0fa:g:OzEAAOSwa81aJs2I)
- https://shop.pimoroni.com/products/booster-header (https://shop.pimoroni.com/products/booster-header)
Both work very well.
There is plenty of clearance with either solution for a Pi3 and a Pi1 so both mate squarely with the connector using these options.
The tall header soldered to the CPC-CPlink card is probably the best option, although I haven't found a good, cheap source for these yet - nearly £4 each is quite pricey for a connector and I would need to add that directly on the cost of any cards I assemble.
The spacer is good too. It fits much more securely that I had expected and you can hang a relatively heavy full size Pi on it without any worries. Remember that the CPC-CPlink board has screw fixing holes to mate with those on the Pi, so if in doubt you can always use those to make a totally robust fixture. I wouldn't worry too much though. Just plugging straight into the header seems fine.
Great project and very promising! I had some thought about how to bootstrap - how to start using the companion processor - without needing a custom ROM or a utility. And I think it's as simple as a Basic one-liner which is easy to memorise and type in, such as:
FOR A=900 TO 933:POKE A,INP(&FD80):NEXT:CALL 900
This would download a short block of code from the coprocessor, supposing it's been set up appropriately, and that code can then start up a more sophisticated and useful protocol, maybe add some RSX facilities, like |LOAD, |RUN, |CHAIN, or |SAVE.
I did get a bit sidetracked on how to do this one-liner as a REM statement, using only printable characters which happen to be a legal Z80 program - discussion here (https://retrocomputingforum.com/t/programming-z80-using-only-printable-characters-a-challenge/822?u=eds) - but I think that was a red herring. Even if the REM comes out shorter, it's harder to type, easier to get wrong, and very difficult to memorise. And it turns out the subset of Z80 you get is only just good enough for the job, and has to begin by constructing some inaccessible opcodes and operands.
Hi all,
I have written the commands i talked about previously for the CPC and PI side as previously discussed.
An initial set of services are provided that can be called on the CPC with the provided BASIC programs are:
PING - are we connected to a listening PI?
SHUTDOWN - to shutdown the pi safely
TIME - gets the current time from the PI
DATE - gets the current date from the PI
RESET - resets the PI side of the communication (free's memory, closes files etc).
I am current working on a memory paging system. It allows the pi to read/save (multiple) files (or just provide memory), and the CPC to page them (a xKB page at a time) in and out of its memory space. The CPC side will be basic to start with and the demo app will be an ASCII file reader i think.
Where is the code you ask - Revaldinho has it and will be releasing on his github page shortly!
While the initial programs are BASIC i hope to provide assembler versions of them in the future but they are currently a reasonable demo app that's easy to understand. Yes i know my basic sucks - :D wait till you see my assembler :o
Here are a few screenies to show you it working - everything is deliberately verbose in v0.1 so lots of screen chatter.
cheers
shiftes
@revaldinho (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1776) - Looking good :) . I shall have to visit your GitHub page.
@shifters74 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=3007) - Nice to see someone developing code for this new card already :)
Mark
Quote from: 1024MAK on 12:16, 20 November 19
@revaldinho (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1776) - Looking good :) . I shall have to visit your GitHub page.
@shifters74 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=3007) - Nice to see someone developing code for this new card already :)
Mark
Thanks Mark
@shifters74 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=3007) 's MCP code is uploaded into GitHub now too - see the sw/examples/mcp folder.
BTW @1024MAK (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1522) - I will be at the ABUG meet this weekend and I see your name down too. I'll be bringing a '464 with my RAM board to show it running FutureOS and maybe other '6128 only' things. I'll bring the FIFO card and some RaspberryPis too, so drop by and say hello.
Quote from: revaldinho on 13:28, 20 November 19
BTW @1024MAK (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1522) - I will be at the ABUG meet this weekend and I see your name down too. I'll be bringing a '464 with my RAM board to show it running FutureOS and maybe other '6128 only' things. I'll bring the FIFO card and some RaspberryPis too, so drop by and say hello.
Great :) Will be nice to see your CPC boards in action.
If you have any boards / PCBs that are available for sale (any of your projects), please bring some along.
Mark
I nabbed a table next to revaldinho at this weekend's ABUG meetup, and we were able to make some good progress on the CPC+Pi combo. It's the first time I've seen it in action, and the possibilities are endless, especially with a Pi that has WiFi.
My main fascination is with ROMless and diskless booting - an unmodified and unenhanced CPC with a CPLink board should be able to do interesting things, with just a one-line boot command written in Basic. And indeed we succeeded! We went through several iterations, and the current winner is this:
FOR A=100 TO 160:POKE A,INP(&FD80):NEXT:CALL 116
That Basic boot command pulls down a short chunk of Z80 code from the Pi, which can then offer all manner of wonders, by loading a longer chunk. I'm pretty sure we can make this idea compatible with, and perhaps an extension of, shifters74's idea of a server which responds to commands.The most visible success we had is the loading of Defend or Die in a fraction of a second. Here's a before and after hitting the enter key, with a slightly earlier and clunkier incantation of the boot:(https://retrocomputingforum.com/uploads/default/optimized/2X/8/869516253047e29180ef78665ec08b47404f5ae6_2_666x500.jpeg)(https://retrocomputingforum.com/uploads/default/optimized/2X/4/48876e816e7e0c0bd3b7dfa5a94e63df126530ee_2_666x500.jpeg)
It was an impressive demonstration :P
Mark
HI guys,
i have finished writing and am just testing my next build (0.2) which includes the following commands:
/**********************************************************************************/
/* These commands control moving pages of memory in/out of the CPC to/from the pi */
/* Using allocation_id's you can have a number (default 20) different areas of */
/* of memory allocated and you can request and store pages to each area seperately*/
/* When you work with a memory allocation you work with RPAGE and SPAGE and work */
/* with page size as specified in the CPAGE command e.g. if you specified */
/* CPAGE 5 8\n then you will have 5 pages of 8K and each RPAGE or SPAGE will work */
/* with an 8KB page at a time. */
/* CPAGE will create the number and size of pages requested in PI memory */
/* and return the allocation_id of that memory allocation */
/* Any use of the other commands MUST have CPAGE performed first. */
/* */
/* FPAGE will free the memory allocation created by a CPAGE. */
/* */
/* RPAGE is used by the CPC to fetch a page from the PI memory to its memory */
/* The size of the page retrieved is what you specified in CPAGE */
/* */
/* SPAGE is used by the CPC to store a page from its memory to the PI memory */
/* The size of the page to be stored is what you specified in CPAGE */
/* */
/* PILPAGES is used by the CPC to tell the PI to load a file into its memory */
/* The CPC can then page the loaded file in and out of CPC memory from */
/* the PI's memory */
/* */
/* PISPAGES is used by the CPC to tell the PI to save its memory back to */
/* file on the PI storage */
/* */
/* See each function for format of the messages */
/**********************************************************************************/
Included within this build is automatic flow control of the queues, a retry mechanism for commands when they are unable to proceed, multi stage commands and better shutdown etc.
This is the base for my next commands (0.3) which are FILEREAD and FILEWRITE to and from the PI to CPC storage.
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).
regards
shifters
Quote from: shifters74 on 09: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.
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:
(https://stardot.org.uk/forums/download/file.php?id=35407&t=1)
(https://stardot.org.uk/forums/download/file.php?id=35409&t=1)
(https://stardot.org.uk/forums/download/file.php?id=48772&t=1)
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
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?
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.
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.
Quote from: biged on 18: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
Quote from: biged on 18: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
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 18: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?
Quote from: shifters74 on 20: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. :)
Quote from: GUNHED on 21: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
Quote from: LambdaMikel on 18: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.
Quote from: shifters74 on 22: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. :)
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
Quote from: shifters74 on 15: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
Quote from: GUNHED on 16: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
... also, I am still dreaming of using my CPC for email... preferably from BASIC with a couple of RSX commands.
END OF LINE
I'm not quite sure about your proposed protocol enhancements, @shifters74 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=3007) 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.
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/ (http://www.cpcwiki.eu/forum/programming/interrupts-questions/msg164115/)
Quote from: LambdaMikel on 20: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
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
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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=58) 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.
Hi Biged,
the payload can be 1 byte to 32K bytes per message - we are not on analogue modems no slip/ppp required!
shifters
Quote from: zhulien on 01: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/ (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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=58) was first in the use of the epic cinematic name 8)
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.
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). :)
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
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
- MC START/BOOT PROGRAM WITHOUT reseting firmware jumpblock? (http://www.cpcwiki.eu/forum/programming/mc-startboot-program-without-reseting-firmware-jumpblock/msg169970/#msg169970)
(Notably, @ikonsgr (http://www.cpcwiki.eu/forum/index.php?action=profile;u=541) and @Docent (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1534) 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.)
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.
@zhulien (http://www.cpcwiki.eu/forum/index.php?action=profile;u=58) , I can't see the Google Sheet in the Forum post, it just says
(https://ssl.gstatic.com/docs/common/product/spreadsheets_lockup1.png) (https://support.google.com/docs/)We're sorry. This document is not published.
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.
The Forum did have a chat function for a while, but it was removed later. Probably due to no-one using it.
Bryce.
Quote from: Bryce on 11: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.
Do you know if it had persistent channels like IRC? or Just a temporary peer to peer chat while the session exists?
I think it was just temporary, but you'd have to ask @Gryzor (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1) .
Bryce.
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...
Rather than me hi-jacking this thread, I will create another non-hardware specific Driver thread.
Needs to be split into 3-4 parts please.
Quote from: shifters74 on 18:16, 29 November 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?
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 (the text equivalents were proof of concept and will be removed in 0.3 as the binary will be the api to use memory and hence the text ones dont make much sense so will be removed.)
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 cpc e.g. "ls -al"
6) Optimisation of the incoming binary pathway (BinaryData coming from cpc to pi)
cheers
shifters
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
Quote from: biged on 17:00, 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.
Quote from: biged on 17:00, 05 December 19
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
Please see http://www.cpcwiki.eu/forum/programming/cpc-drivers/ for zhulien's thoughtful look at developing a driver standard.
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
Quote from: shifters74 on 12:11, 10 December 19
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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=3007) - 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.
@revaldinho (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1776) - I'll be in touch via PM ;)
I've been experimenting with my new cplink trying to create an interface between the CPC and MQTT for home automation. One think I have noticed is when using a python script on the RPi and a C program on the CPC, I seem to lose a lot of data in the transfer! I'm assuming this is due to the buffer in the FIFO becoming exhausted because its not being drained quickly enough, confirmed by inserting a delay in the send loop on the CPC - but I had assumed that even running python the RPi would never be outpaced by the CPC!? Does this sound correct, if so is there a better way to solve the problem other than:
- Running a C program on the RPi to speed things up
- Slowing the CPC down with an artificial delay in the tx loop?
Both solutions seem to me like they might still be error prone and only work due to good fortune. I guess, as has been discussed earlier in this thread, what i may need is some kind of packet based protocol with parity checking but that seems very heavy weight for my simple needs.
Cheers!
Nic
You won't need any delay loops, provided you're checking the status registers and reacting accordingly. A writer should not write a byte until there's space in the FIFO, and a reader should not read a byte unless there's something to be read. So, at both ends of the link and in both directions you need to be checking the status register.
On the wiki (https://github.com/revaldinho/cpc-cplink/wiki) we see this Basic code:
130 IF i<>1024 AND (INP(&FD81) AND 2) THEN OUT &FD80,tx[i] :i=i+1
140 IF j<>1024 AND (INP(&FD81) AND 1) THEN rx[j]=INP(&FD80):j=j+1
Hi biged
I tried an experiment using only code from https://github.com/revaldinho/cpc-cplink - it involved running the (C) loopback client program on the CPC and the (python) loopback server program on the RPi, and I got thousands of errors, but 0 errors if I ran the C server program on the RPi - this is also what led me to the conclusion that python was too slow. And I can't blame that test on my bad code ;D
Aside from that test,
My CPC C code just uses the fifolib.h/.s library so it think that this should handle checking the status registers also?
I will double check what my python code is doing but it is basically a copy and paste of loopback_wpi.py from the repo with a few extensions of my own but the send/receive functions are unchanged and appear to check the registers.
Cheers!
Nic
I think you might have just got out of sync. If you leave the loopback code running on the Pi while stopping and starting the CPC program, then the Pi will be attempting to return values from a previous run.
If you kill both the Pi program and the CPC one, power cycle the CPC, then restart the Pi program and then the CPC program do you still see the errors ?
(don't forget that to reset the FIFO from the CPC side you need to write to the status register - OUT &FD81,0 )
When using the status register for checking byte by byte there's no limit on how slowly you can run - see the demo with the CPC running BASIC and the Pi using Python ... :D
I just tested this here to remind my self of what's supposed to happen with the short demo... :D
Running in C on the CPC and Python on a Pi 3A+ I get this (see snap in the attachment) - ie no errors for Test 1 and 2 which check the FIFO status on every byte transferred, but lots of errors on Test 3 which doesn't do any status checks at all.
This is normal.
YMMV on Test3 as the error rate will depend on the speed of your Pi and what else you might have set the Raspbian distro to be doing while the loopback code is running. The same Pi loopback implemented in C can often get zero errors here on my 3A+ ... but never on my Zero. I think that this is what you might mean by the Pi Python showing errors but the C version not ?
The key thing is that tests 1 and 2 are 100% reliable but the byte by byte status check limits maximum throughput to about 50KBytes/s in either direction. The limitation is simply the speed at which the Z80 code can check status and send/receive bytes.
Test 3 give interesting results on different Pis and with different implementations of the Pi loopback, but really it just confirms that trying to implement a blind burst mode (where speed can go above 100KBytes/s) needs to be accompanied by CRC type packet checks and the ability to retransmit. I think that the overhead for doing this probably outweighs any saving made in the raw bit rate, so I recommend always to use the byte-by-byte status checks.
Once you've run this test and seen that the last test3 has reported errors, you need to stop and restart the pi loopback side of the demo, because the pi is continuing to receive and sent bytes whether the FIFO is ready or not ... which is what I meant by being out of sync.
[size=78%] [/size]
Hmm strange I was getting errors on all 3, but will check again with a clean start of everything
OK, seems like that was it! I ran same configuration again, 1st 2 tests worked last one failed, then ran again without restarting the server and all 3 tests failed. So that must have been what happened last time, or something similar.
Am i right in assuming using the fifolib's fifo_out_byte function like this:
https://github.com/revaldinho/cpc-cplink/blob/master/sw/examples/loopback/cpc_cpct/fifo/src/main.c#L57
...then that will handle any checking of the status registers for me? I.e. I can just keep calling that method as fast as I like and it'll block until it has managed to put the byte on the FIFO? Just it does not appear to be checking anything in the code above before making the call.
Cheers!
Nic
Right, that all makes sense then. :D
fifo_out_byte (data ) doesn't block - it returns 1 if a byte was successfully transmitted or 0 if the FIFO was not ready. In the loopback code example you pointed to , that call is in the middle of a loop and you can see that the data pointer 'i' is incremented only when a byte has been sent successfully otherwise a new attempt to send the byte will be made next time around the loop.
Here's the actual code for the routine from the library file
https://github.com/revaldinho/cpc-cplink/blob/master/sw/examples/loopback/cpc_cpct/fifo/src/fifolib.s (https://github.com/revaldinho/cpc-cplink/blob/master/sw/examples/loopback/cpc_cpct/fifo/src/fifolib.s)
;; --------------------------------------------------------------
;; fifo_out_byte (__z88dk_fastcall)
;; --------------------------------------------------------------
;;
;; Write a single byte and store it in the location pointed to by
;; a parameter.
;;
;; Entry
;; - L holds byte to be written
;;
;; Exit
;; - L =1 if successful, otherwise zero
;; - AF, BC corrupt
_fifo_out_byte::
ld bc, #0xfd81
in a,(c) ; get dir status flag
and #0x2
jr z,fob_end ; go to end if no data available
dec c ; point to data reg
out (c), l ; write the byte
ld a, #0x1 ; success
fob_end:
ld l,a
ret
Often you can use fifo_out_bytes(pointer, num_bytes) too - in a similar way this one returns the number of bytes written successfully(which may be 0) but again doesn't block. When sending lots of data this one is faster as it loops over the bytes in assembly language and does some loop unrolling to speed things up too.
If you want to check that a FIFO is ready for data to be written out then use fifo_get_dir() first. (And to check that the FIFO has data waiting to be read, you can check fifo_get_dor()). Alternatively just repeatedly call fifo_out_byte until it returns a 1.
If it's useful to have some blocking versions of these then I can easily add them to the library. It's only a code example really, but if it can be more generally useful that would be a good thing.
I see what you mean, it's just going to keep trying until it sends the lot, and will only increment the counter to get the next byte when successful.
I can write a blocking version which checks fifo_get_dir first so that's no problem!
Im assuming if fifo_out_bytes returns anything less than num_bytes, its safe to continue next time at pointer+(the return value)
Cheers!
Nic
Quote from: nicf82 on 17:54, 27 May 20
Im assuming if fifo_out_bytes returns anything less than num_bytes, its safe to continue next time at pointer+(the return value)
Yes, that's the thing to do.
I just checked in an updated fifolib now which gives you blocking versions anyway
byte = fifo_get_byte()
fifo_put_byte( byte ) + an updated version of the test to check them.
Wow thanks revaldinho that was a quick turnaround ;D
Make sure to get the very latest checkin - I pushed a typo in my first update. Fixed now. :picard:
While I'm here and having just run the tests again, this is what I see with the Pi 3A+:
Test1 = send/receive the bytes checking status each time using fifo_in_byte/fifo_out_byte (non-blocking)
Test2 = send/receive the bytes checking status each time using fifo_get_byte/fifo_put_byte (blocking)
Test3 = send/receive multiple bytes checking status for each using fifo_in_bytes/fifo_out_bytes (non-blocking)
Test4 = send/receive bytes with no status checking on the CPC side - assumes the Pi can always keep up...
Pi (Python/WiringPi) + CPC (C/fifolib): Test 1 = 1.7s , Test 2 = 1.27s, Test 3 = 0.51s, Test 4 = 0.15s (many errors)
Pi (C) + CPC ( C/fifolib): Test 1 = 1.7s, Test 2 = 1.07s, Test 3 = 0.32s, Test 4 = 0.15s (no errors)
... so note that the tests are renumbered now so that Tests 1 to 3 should always be error-free, and it's Test 4 which is the one relying on a fast Pi not preoccupied with other tasks to be able to keep up.
The CPC C loop for the blocking tests is simpler than the one for the non-blocking one which explains most of the improvement between Tests 1 and 2.
who else has a CPC-CPCLINK card?
Quote from: zhulien on 15:24, 10 September 21
who else has a CPC-CPCLINK card?
I have one, too
I have one complete and enough components to build a second.
I have one and did some coding (the MCP and commands in examples) with it, but not done much else since 2019 as there seemed little interest in it.
Nice hardware though from Rev!
shifters
Reviving what is now a bit of an old thread, I agree that there has been little interest in the CPLINK project even though it seems to offer a very simple way of using modern MCUs as soft-peripherals on the CPC. At the same time there are then several other threads suggesting someone implements a generic interface to a RaspberryPi or Pico to allow many of the things that CPLINK already makes possible.
So, by way of a long overdue update let's look at one of those often suggested applications: using a RaspberryPi as a dedicated graphics processor, providing a high resolution second screen to the CPC, and easily accessible from CPC BASIC. This could be a cheaper and easier to source alternative to other dedicated GPUs which often get discussed, for example the V999x boards.
This week
@biged and I went to the ABUG meetup in Camberley (https://stardot.org.uk/forums/viewtopic.php?f=25&t=24130) and with surprisingly little code put a simple version of this application together.
Here's our first BASIC demo program running:
Instead of inventing a new graphics API for the GPU we decided to adopt the BBC Micro's VDU control code (https://beebwiki.mdfs.net/VDU) system. It's well documented and a good starting point, and even better we were able to write the Pi side of the program in BBC BASIC for SDL (https://www.bbcbasic.co.uk/bbcsdl/index.html) which meant we didn't need to actually do any of the work in emulating the VDU code processing. CPLINK takes care of all critical timing in the interface with the CPC so, for the purposes of this demo at least, it doesn't matter that BBC BASIC is a relatively slow language running on a full Raspbian distribution.
In this demo the Pi is acting purely as a GPU, accepting control codes and data and drawing the graphics. In fact this is the entire inner loop of the BBC BASIC GPU code - wait for a byte and then send it to the VDU stream:
REPEAT
IF FN_gpio_get(gpio%, PIN_DOR%)<>0 THEN
c%=FN_read_fifo_byte
PRINT CHR$(c%);
ENDIF
UNTIL 0The CPC host is running a BASIC program doing all the calculations for line positions and sending the graphics commands to the Pi via CPLINK.
We already had generic RSXes for transferring data over CPLINK, but to make things more convenient in CPC BASIC, we implemented some new RSXes. There is a generic |VDU command which is fully compatible with the all the Acorn codes and parameters. There are also dedicated |PLOT and |ORIGIN commands which deal with the slight complication of taking 16 bit parameters and sorting the bytes out into the right order. The RSXes can be placed in ROM (slow to look up...) or in RAM (much better).
Here is the entire code for the CPC BASIC progam showing off the use of the RSXes:
1 REM Walking Lines - adapted from CTR's code on
3 REM the 'unattended beebs' thread on stardot.org
5 REM Uncomment the next line if not using RSXes in ROM
9 REM MEMORY &97FF:LOAD "fiforsx.bin",&9800: CALL &9800
10 DEFINT A-Z
20 N=8:MX=3200:MY=2400
30 |VDU,20:|VDU,16:|VDU,26
40 |VDU,23,1,0,0,0,0,0,0,0,0
50 X=MX/2:Y=MY/2:A=2*MX/3:B=2*MY/3
60 V=32:W=24:C=16:D=-28
70 DIM E(N),F(N),G(N),H(N)
80 start!=TIME
90 FOR K=1 TO 25
100 FOR I=1 TO N
110 |VDU,18,0,0
120 |PLOT,4,E(I),F(I):|PLOT,5,G(I),H(I)
130 E(I)=X:F(I)=Y:G(I)=A:H(I)=B
140 |VDU,18,0,I
150 |PLOT,4,X,Y:|PLOT,5,A,B
160 X=X+V:Y=Y+W
170 IF X>MX OR X<0 THEN V=-V
180 IF Y>MY OR Y<0 THEN W=-W
190 A=A+C:B=B+D
200 IF A>MX OR A<0 THEN C=-C
210 IF B>MY OR B<0 THEN D=-D
220 NEXT
230 NEXT k
240 |FIFOPUTS, " Runtime "+STR$((TIME-start!)/300)+"s"+CHR$(10)+CHR$(13)
250 |FIFOPUTS, " Num Lines"+STR$(N)+CHR$(10)+CHR$(13)
260 |FIFOPUTS," Iterations"+STR$(K-1)+CHR$(10)+CHR$(13)
270 |FIFOPUTS," Coordinate Area"+STR$(MX)+" x"+STR$(MY)+CHR$(10)+CHR$(13)There's no real comparison between the performance of the CPC running the same code locally with a 320x200 pixel Mode 1 screen and the hi-res output through the GPU. Just to give a flavour though, a simple Amstrad version plots 25 iterations of 8 lines over a virtual 640x400 coordinate area in 21.4s. The same number of iterations running over a virtual 3200x2400 (actual 1600x1200) screen using the Pi GPU takes 8.5s.
I think we'll probably port some more BBC BASIC graphics demos to the CPC for a bit of fun while we're thinking about the next steps here, but already we know that we'd like the Pi client to handle other traffic as well as VDU output. In the meantime, the GitHub Project (https://github.com/revaldinho/cpc-cplink) has been updated with a new section in the code examples (sw/examples/vdu) for anyone who already has a CPLINK and a PiZero and would like to try this out.
fantastic news, so if I have understood it correctly to test it on my CPClink, I must run the example code in basic on my CPC6128 with the CPCLink expansion connected to my MX4 board, right? , and the pizero, connected to a monitor? , and where is file "fiforsx.bin" ? , thx :)
awesome, i wonder how many firmwares to patch then to use the PI as the primary CPC display (except when running a native CPC game).
Quote from: XeNoMoRPH on 06:58, 22 March 22fantastic news, so if I have understood it correctly to test it on my CPClink, I must run the example code in basic on my CPC6128 with the CPCLink expansion connected to my MX4 board, right? , and the pizero, connected to a monitor? , and where is file "fiforsx.bin" ? , thx :)
Yes, it's very much like running the loopback test. You need to start up the Pi with the vdu program running to set up the GPU client. Then load and run the CPC BASIC on the host.
All the sources are checked into git, but you do have to build the binaries. I'll copy them into a .dsk file and also provide the .bbc file (for the Pi) in this thread later today which will make it easier to get started.
Building from source you need rasm (https://github.com/EdouardBERGE/rasm) installed and then you can run the Makefile in the /sw/commonlib/cpc_asm area to generate the fiforsx.bin and fiforsx.rom files. Then go to /sw/examples and run the Makefile there to build a .dsk image which will include all the CPC BASIC programs and binaries.
On the Pi side, you need to have BBC BASIC for SDL installed on the full Raspbian. This recipe worked for me:
# Install SDL
sudo apt install libsdl2-dev -y
sudo apt install libsdl2-image-dev -y
sudo apt install libsdl2-mixer-dev -y
sudo apt install libsdl2-ttf-dev -y
sudo apt install libsdl2-ttf-2.0-0 -y
sudo apt-get install libsdl2-net-2.0-0 -y
sudo apt-get install mesa-utils -y
# Get BBC BASIC
mkdir BBCSDL
cd BBCSDL
wget https://www.bbcbasic.co.uk/bbcsdl/bbc-rpi.zip
unzip bbc-rpi.zip
cd ..Once that's installed you can start BBC BASIC, picking Richard Russell's 'SLIDE' IDE option. Load the vdu.bas code and run it to see the VDU client running in an X window.
To run the client in full screen mode you need to save out the program as a tokenised version, vdu.bbc from the IDE. Quit the IDE and now you can run from the command line with
./bbcsdl vdu.bbc -fullscreen
(The command line will only accept the tokenised BASIC rather than the ASCII version).
Escape and *QUIT will exit the vdu client to get back to the Pi OS.
If you add this command line to your /etc/rc.local file then the Pi will boot up directly into the full screen vdu client on startup. No need to have keyboard and mouse connected to the Pi after that
One note on the Pi - BBC BASIC for SDL wasn't happy on my old Pi Zero V1.3 ('illegal instruction'), but runs fine on my 3A+ and Pi Zero W2.
I will wait for your DSK, thanks ;)
Here is a .DSK image with the CPC BASIC demos and RSX binaries + a tokenised version of the Pi Client program vdu.bbc (which I had to zip to be able to attach it here).
One slightly odd thing with the BBC BASIC is that when running full screen the coordinate area is 3200x2400 (on my 1600x1200 monitor) but when running in a window it is the 1280x1024 you'd expect from the old BBC Micro. So when running the demos you might have to edit a line or two to set the display size (see the comments).
Excellent. I 've just bought a Pi Zero '2' to reinvigorate my CPC-CPLINK project. This has come at just the right time!
Thanks, Richard.
Once you get your Pi GPU Client set up there are some good listings in this book which can be easily adapted with the new |VDU commands:
Advanced Graphics with the BBC Microcomputer (http://www.flaxcottage.com/Misc/Advanced%20Graphics%20BBC.pdf)
The |PLOT and |ORIGIN RSXes take the same arguments as on the Beeb, and these and all other VDU codes are documented here (https://beebwiki.mdfs.net/VDU).
OK, starting the CPC-CPLINK as my next project. Should be OK making the board, having successfully built the eight rom board and old school ram expansion (great projects btw), but I am starting at square one with the pi. First complication I think I have, is that I have an old model b rev 1 pi. From what I have read the gpio pin out is slightly different but unsure what the implications are. Any help much appreciated.
Quote from: Rabs55 on 19:24, 22 June 22OK, starting the CPC-CPLINK as my next project. Should be OK making the board, having successfully built the eight rom board and old school ram expansion (great projects btw), but I am starting at square one with the pi. First complication I think I have, is that I have an old model b rev 1 pi. From what I have read the gpio pin out is slightly different but unsure what the implications are. Any help much appreciated.
CPC-CPLINK will work with the older Pis because it only uses pins which are common to the old 26W and the newer 40W Pi connectors. For the very oldest Pis though you will need to adjust pin numbers in some of the demo code.
There's a summary of the pin changes here: https://www.raspberry-pi-geek.com/howto/GPIO-Pinout-Rasp-Pi-1-Rev1-and-Rev2
Using a full size Pi is ok but you will find that you need to use a tall connector on the CPLink board (see earlier in this thread) or else the ethernet box on the Pi will prevent the board fitting flush.
For the BBC BASIC GPU demo you will need a much newer Pi - a 3 A+ or a Zero W2 for example. The BBC BASIC interpreter just won't run on earlier boards with older ARM cores.
Quote from: revaldinho on 04:22, 24 June 22Quote from: Rabs55 on 19:24, 22 June 22OK, starting the CPC-CPLINK as my next project. Should be OK making the board, having successfully built the eight rom board and old school ram expansion (great projects btw), but I am starting at square one with the pi. First complication I think I have, is that I have an old model b rev 1 pi. From what I have read the gpio pin out is slightly different but unsure what the implications are. Any help much appreciated.
CPC-CPLINK will work with the older Pis because it only uses pins which are common to the old 26W and the newer 40W Pi connectors. For the very oldest Pis though you will need to adjust pin numbers in some of the demo code.
There's a summary of the pin changes here: https://www.raspberry-pi-geek.com/howto/GPIO-Pinout-Rasp-Pi-1-Rev1-and-Rev2
Using a full size Pi is ok but you will find that you need to use a tall connector on the CPLink board (see earlier in this thread) or else the ethernet box on the Pi will prevent the board fitting flush.
For the BBC BASIC GPU demo you will need a much newer Pi - a 3 A+ or a Zero W2 for example. The BBC BASIC interpreter just won't run on earlier boards with older ARM cores.
Thanks again, super project. Got it working. Really pleased. Had to mount the model B PI on a double header, remove the composite video connector and lift the expansion card up on a box to give clearance for the big HDMI cable. Adjusted the pins in the python script and 1024 bytes sent and received, no errors, 153.6 Bytes/s. :)
Quote from: Rabs55 on 18:09, 26 June 22Thanks again, super project. Got it working. Really pleased. Had to mount the model B PI on a double header, remove the composite video connector and lift the expansion card up on a box to give clearance for the big HDMI cable. Adjusted the pins in the python script and 1024 bytes sent and received, no errors, 153.6 Bytes/s. :)
That's good to hear. That data rate is limited by the CPC BASIC loops rather than Python on your first generation Pi B. You can do a lot better in BASIC by sending multiple characters each time round the loop, but to get to the 50KBytes/s rates (with full handshaking) you'll need to use the libraries for BCPL, C or assembler.
I still recommend a Pi Zero W2 though - the GPU/hi res second screen application is very accessible once you can run the BBC BASIC client on the Pi.
Quote from: revaldinho on 19:54, 10 November 19Electrically, the card can interface to a wide range of co-processors using either 5V or 3V3 signalling.
Did I see that correctly on the PCB that /OE of
74HCT245N is put to GND? So basically it's always passing through data from one side to the other, right?
Yes. One '245 deals with unidirectional control signals and is always enabled with fixed direction. The other deals with the bidirectional data between FIFO and co-pro. The co-pro deals with '245 direction and output enabling of the FIFO tristate pins in this case.
R
(BTW the 245s are from the level shifting LVC family rather than HCT types).
Quote from: revaldinho on 11:55, 18 August 22(BTW the 245s are from the level shifting LVC family rather than HCT types).
Ouch.. you are right... I was searching with Google and my favourite shop came up, but they only had the HCT type. Thanks for pointing that out, I might have ordered the wrong chips.
Do you have a quick start guide to setup the pi for pi-side dev?
Quote from: zhulien on 15:51, 18 August 22Do you have a quick start guide to setup the pi for pi-side dev?
There should be all you need to know to get started on the GitHub wiki (https://github.com/revaldinho/cpc-cplink/wiki). That describes how to get the basic loopback tests working, and you will find example code in the sw/ folder of the repository. Once you've managed to run a loopback then getting the BBC BASIC VDU code demo running is fairly straight forward, but see earlier in this thread for a list of additional Raspbian dependencies to install.
Finally got my second monitor setup. Still can't source a Raspberry PI zero for a sensible price so the Model B will have to do.20220818_180509 (1).jpg
I saw one of the threads was about video steaming from the pi, what was the throughput?
Has anyone set a CPLink up as a print server, ie to interface a CPC to a WiFi printer?
Quote from: zhulien on 15:05, 09 September 22I saw one of the threads was about video steaming from the pi, what was the throughput?
Raw throughput is ~50KBytes/s when using byte-by-byte handshaking.
The CPC is always the limiting factor. For Pi to CPC I think that's about the limit. For CPC to Pi, it's possible for the Pi to empty the 16byte FIFO faster than the CPC can fill it. In this case the CPC can skip the FIFO-full checks on transmission and get over 100KBytes/s for block transfers.
I have found my CP-Link card and my Raspberry Pi, for some reason they are no longer connected - do you have an image on how to connect them?
Update: I just realised I have the wrong one, I did buy a correct one, but I need to find it.
Hi Zhulien
First page of this thread has some snaps like this one showing a 3A+ on the back
(https://www.cpcwiki.eu/forum/dlattach/?attach=29996)
and on the GitHub wiki (https://github.com/revaldinho/cpc-cplink/wiki) there are full instructions, including this one showing a Zero.
(https://raw.githubusercontent.com/revaldinho/cpc-cplink/master/doc/ExpBoardCPCLINK_rear.jpg)
If you haven't used it for a while then I just bring this section of the instructions (https://github.com/revaldinho/cpc-cplink/wiki#coprocessor-uart-interface) to your attention - ie don't fit the link in the top left corner of the board if using USB power for the Pi. There are markings on the PCB to this effect, but still worth a mention.
(https://raw.githubusercontent.com/revaldinho/cpc-cplink/master/doc/HeaderDetail.jpg)
Good news, found my 3b, it was part made into the other cpc pi project so unplugged it for cpc link. For some reason new PIs are expensive now.
At the pi side, what os do you recommend and are you using wiringpi? Do we currently have a protocol for the asynchronous comms or not yet? (So everyone's use of the pi can coexist), i am thinking of a GUID (maybe smaller version) to identify projects or uses - eg... a way for a software to uniformly send an image to the pi for display, send and retrieve files, play music on PI side, give me the displaylist already calculated for matrix transformations etc, basically some command structure for which different commands can take their own set of parameters.
On the cpc side we would just make calls with an incremental call ID and a single background task that listens for a response and the response would have the original call id so we can match responses with the original calls.
Quote from: zhulien on 17:42, 17 September 22At the pi side, what os do you recommend and are you using wiringpi?
In the sw/examples/loopback (https://github.com/revaldinho/cpc-cplink/tree/master/sw/examples/loopback) dir there are examples in C and Python using WiringPi and also Python using RPI.GPIO.
Quote from: zhulien on 17:42, 17 September 22Do we currently have a protocol for the asynchronous comms or not yet? (So everyone's use of the pi can coexist), i am thinking of a GUID (maybe smaller version) to identify projects or uses - eg... a way for a software to uniformly send an image to the pi for display, send and retrieve files, play music on PI side, give me the displaylist already calculated for matrix transformations etc, basically some command structure for which different commands can take their own set of parameters.
On the cpc side we would just make calls with an incremental call ID and a single background task that listens for a response and the response would have the original call id so we can match responses with the original calls.
There is currently no API to make it a multi-function peripheral. The GPU demo described in this post (https://www.cpcwiki.eu/forum/index.php?msg=213786) literally just sent bytes conforming to the BBC MIcro VDU stream spec (https://beebwiki.mdfs.net/VDU) (API) directly to the Pi, with the Pi running a client (https://github.com/revaldinho/cpc-cplink/blob/master/sw/examples/vdu/rpi_bbc_basic/vdu.bas) (in BBC BASIC) listening for bytes and using its own VDU processing code to drive the screen. This was a single function demo to show that the PI as a GPU was a cheap option for a second screen and maybe even as a primary screen, say for a patched CP/M or SymbOS where it would offer a good acceleration over the original CPC output.
The Pi can do so much more of course, and
@shifters74 demoed earlier a command protocol system, which is described earlier in this thread (https://www.cpcwiki.eu/forum/index.php?msg=181181). That has stalled and there is no 'official' API to go with the hardware yet, so if you would like to start something in that direction that would be very welcome.
@Prodatron what primitives should I code in a CPC-CPLINK card protocol to make it reasonably easy for you to make a Symbos graphics driver and get reasonable speed?
Dont forget that DevilMarkus is writing a virtual graphic card on his emulator with an API, which could lead to a real graphic card.
He said he would give more informations later, using a common API for this virtual card and the cpclink would be nice.
Quote from: zhulien on 16:06, 20 September 22@Prodatron what primitives should I code in a CPC-CPLINK card protocol to make it reasonably easy for you to make a Symbos graphics driver and get reasonable speed?
SymbOS loves 2D blitters...
- filling rectangle areas with one colour
- copying rectangle areas to/from the cpu (via out/in e.g.)
- copying/scrolling rectangle areas to another vram place
- having a hardware sprite for the mouse pointer
- using and/or/xor for blitting operations (for plotting pre-rendered chars in any colour combinations)
All this is possible with the VDP9938/9958/V9990, but there are even better solutions in progress right now.
Quote from: Prodatron on 21:38, 21 September 22Quote from: zhulien on 16:06, 20 September 22@Prodatron what primitives should I code in a CPC-CPLINK card protocol to make it reasonably easy for you to make a Symbos graphics driver and get reasonable speed?
SymbOS loves 2D blitters...
- filling rectangle areas with one colour
- copying rectangle areas to/from the cpu (via out/in e.g.)
- copying/scrolling rectangle areas to another vram place
- having a hardware sprite for the mouse pointer
- using and/or/xor for blitting operations (for plotting pre-rendered chars in any colour combinations)
Such as
// rectangles here must be in the visible space
areaFill(x, y, w, h, colour, options); // options: copy and or xor
areaScroll(x, y, w, h, xoffset, yoffset, options); // options: wrap, nowrapcolour
areaCopy(x1, y1, w1, h2, x2, y2, options);
areaLoad(m, x, y, w, h, options) // load from cpu ram, options copy and or xor
areaSave(x, y, w, h, m);
// rectangles here can be visible or not or part off-screen and even overlapping
int windowDefine(w, h);
windowSetZ(windowID, z);
windowFill(windowID, colour, options);
windowScroll(windowID, xoffset, yoffset, options);
windowCopy(windowID1, windowID2, options);
windowLoad(m, windowID, options);
windowSave(windowID, m);
windowShow(windowID);
windowHide(windowID);
windowDestroy(windowID);
The areaXXX ops sound good.
What colour depth is planned?
The windowXXX things would be too high level for SymbOS.
Quote from: Prodatron on 08:38, 22 September 22The areaXXX ops sound good.
What colour depth is planned?
The windowXXX things would be too high level for SymbOS.
Ok I will start in it, as it's a virtual gfx card I will likely support the area and window level APIs to make it easier for new software ideally written in basic to use it, windows managed at the PI side frees a lot of comms and such.
In addition to rectangle APIs do you have widgets or do they still use the same APIs?
How does symbos deal with text output?
With colour depth, do you want to query the device for available modes or capabilities or so you have a set of presets at your end, like a mode 1, 2, 0? I'm guess the latter. I am thinking if I support cpc modes and then some more by separately catering for resolutions and colour depths, any combinations you choose.
Any resolution up to 1920 x 1080.
Choice of colour depths: 1 bit, 2 bits, 4 bits, 8bits, 16bits
For colour depths above that eg...24 bits i am thinking how will a cpx realistically use it? Special view image mode? Special play video mode? Of course no point streaming a video using i/o ports in realtime, however we could treat sdcars storage as video ram from a point of view, transfer a video in its entirety to the PI from CPC then play it? Or limit streamed video files to be super low res, such as 160 x 100 up to 16bit colour?
15 bit (+ 1 bit alpha) is more interresting than 16 bit I think.
Quote from: zhulien on 18:57, 22 September 22In addition to rectangle APIs do you have widgets or do they still use the same APIs?
How does symbos deal with text output?
All controls in SymbOS use the three low level methodes
- paint line/fill rectangle
- plot bitmap
- plot text
Textoutput on a system with blitter/VDP (MSX with VDP9938, CPC/MSX/Enterprise/PCW with V9990) is usually done with a pre-rendered system font, which is placed in the invisible area of the video ram. The whole font is stored in 16 different colours and plotted with the blitter char by char on a prepared background with XOR, so you can plot texts with any 16x16 colour combinations with a prepared font.
If an app is using an own font it is done by the CPU->VRAM transfer methode.
Quote from: zhulien on 19:16, 22 September 22With colour depth, do you want to query the device for available modes or capabilities or so you have a set of presets at your end, like a mode 1, 2, 0? I'm guess the latter. I am thinking if I support cpc modes and then some more by separately catering for resolutions and colour depths, any combinations you choose.
Any resolution up to 1920 x 1080.
Choice of colour depths: 1 bit, 2 bits, 4 bits, 8bits, 16bits
SymbOS is able to handle all possible screen resolutions. Currently we have 320x200, 640x200, 256x212, 512x212, 384x240, 768x240, 1024x212 and 768x256. It always depends on the video hardware of the platform.
SymbOS handles colour depths of 1, 2 and 4 bits (2, 4, 16 colours). Support for 8 and 16bit isn't planned and would only be possible for platforms, which can convert colour depths during CPU->VRAM transfer on the fly.
Quote from: Prodatron on 16:20, 23 September 22Quote from: zhulien on 19:16, 22 September 22With colour depth, do you want to query the device for available modes or capabilities or so you have a set of presets at your end, like a mode 1, 2, 0? I'm guess the latter. I am thinking if I support cpc modes and then some more by separately catering for resolutions and colour depths, any combinations you choose.
Any resolution up to 1920 x 1080.
Choice of colour depths: 1 bit, 2 bits, 4 bits, 8bits, 16bits
SymbOS is able to handle all possible screen resolutions. Currently we have 320x200, 640x200, 256x212, 512x212, 384x240, 768x240, 1024x212 and 768x256. It always depends on the video hardware of the platform.
SymbOS handles colour depths of 1, 2 and 4 bits (2, 4, 16 colours). Support for 8 and 16bit isn't planned and would only be possible for platforms, which can convert colour depths during CPU->VRAM transfer on the fly.
I think that's reasonable, if up to 16 colours at full hd resolution, that would give an awesome CPC desktop. For images and video playback, we can look at very specific functions at a later time that really just allow the CPC to pass at a high level the image or video file to the video ram and they can render potentially full colour within a 16 colour desktop.
If I manage to get that far, then I can extend other functions to cater for things that Symbos can optionally support at a later date.
I'm using a Pi 3b currently, and I have ordered a 4b with the refund from Tecnobytes. I do plan to make more use of the other Pi features too but... given everyone here was awaiting a gfx card, I am sure we can find 25 users eventually who would possibly buy a modern Pi alternative gfx card. I've also now got quite a lot of familiarity with CPC Basic disassembly while working on the Locomotive Shell, so no reason* not to have a patched ROM to support the display from there too. * the only reason I can think of is currently available ROM space might need sacrificing some commands if a full BASIC, but given I might be able to do some things at a higher level, I might be able to reclaim some space from that.
How d
Quote from: Prodatron on 16:13, 23 September 22Quote from: zhulien on 18:57, 22 September 22In addition to rectangle APIs do you have widgets or do they still use the same APIs?
How does symbos deal with text output?
All controls in SymbOS use the three low level methodes
- paint line/fill rectangle
- plot bitmap
- plot text
Textoutput on a system with blitter/VDP (MSX with VDP9938, CPC/MSX/Enterprise/PCW with V9990) is usually done with a pre-rendered system font, which is placed in the invisible area of the video ram. The whole font is stored in 16 different colours and plotted with the blitter char by char on a prepared background with XOR, so you can plot texts with any 16x16 colour combinations with a prepared font.
If an app is using an own font it is done by the CPU->VRAM transfer methode.
I am guessing that the V9990 has it's own memory map or own method of paging and poking memory via I/O ports - is there a good document on how the memory is laid out on the V9990? Or more importantly how does Symbos address memory, is it via an id, or a bank+address output to a certain address? What is the address space size and you mentioned non-visible memory, is the V9990 flexible enought to make anything visible or not, or does it have dedicated memory types, such as attribute RAM, storage RAM, visible RAM?
Quote from: TotO on 19:30, 22 September 2215 bit (+ 1 bit alpha) is more interresting than 16 bit I think.
What is the purpose of a 1 bit alpha - is it like a half-bright bit?
Quote from: zhulien on 16:33, 23 September 22I am guessing that the V9990 has it's own memory map or own method of paging and poking memory via I/O ports - is there a good document on how the memory is laid out on the V9990? Or more importantly how does Symbos address memory, is it via an id, or a bank+address output to a certain address? What is the address space size and you mentioned non-visible memory, is the V9990 flexible enought to make anything visible or not, or does it have dedicated memory types, such as attribute RAM, storage RAM, visible RAM?
The VDP9938/9958/V9990 are completely accessed via I/O ports including all registers and vram.
The V9990 is very similiar to the older VDPs (9938, 9958).
You have some ports for setting registers and sending/receiving data.
There are ports for setting the VRAM read/write address and a port for sending/receiving data from the VRAM. There are also registers for defining a rectangle inside the vram where you then can write/read bytes to/from.
You can define the visible resolution and the virtual resolution (which can be bigger) and an X/Y offset. The old VDPs have 128K vram, the V9990 has 512K vram, and so you won't see all vram at the same time on the screen, so you have invisible parts.
For the colour palette you have dedicated registers, this is not stored in the vram.
The pattern mode is a different story, but this isn't used by the SymbOS GUI, this is only used by the new SymbOS fullscreen V9990 games with the Quigs engine.
I found this, I will have a read
http://map.grauw.nl/resources/video/yamaha_v9990.pdf
Transparency. It can allows to overlay another video source.
And you have a perfect 5bit RGB cube for the colours palette.
Quote from: biged on 21:16, 27 November 19I'm not quite sure about your proposed protocol enhancements, @shifters74 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=3007) 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.
I am considering the application allocating an id when there are multiple at once, they can ignore the id if they don't care about it in a single app environment which takes over the whole machine, choice is theirs. The id is to match a request with a response for asynchronous calls. I will support both blocking and asynchronous however. Even in a single app situation they could mix and match, e.g. a graphics update which requires as fast as a call as possible might be blocking, and another call which may not be as time dependent like play an mp3 might not be. There will be a background timer on the cpc that takes in requests from the PI in addition to asynchronous responses. The PI also can initiate these requests e.g. we could have the pi asynchronously feeding the cpc something. This will happen as part of my MCP ROM but I will make sources available. The ROM allows quite a few cool things currently - spawning of tasks and even surviving a system reset, keeping the tasks running - with an optional bypass.
Quote from: revaldinho on 10:18, 22 March 22Quote from: XeNoMoRPH on 06:58, 22 March 22fantastic news, so if I have understood it correctly to test it on my CPClink, I must run the example code in basic on my CPC6128 with the CPCLink expansion connected to my MX4 board, right? , and the pizero, connected to a monitor? , and where is file "fiforsx.bin" ? , thx :)
Yes, it's very much like running the loopback test. You need to start up the Pi with the vdu program running to set up the GPU client. Then load and run the CPC BASIC on the host.
All the sources are checked into git, but you do have to build the binaries. I'll copy them into a .dsk file and also provide the .bbc file (for the Pi) in this thread later today which will make it easier to get started.
Building from source you need rasm (https://github.com/EdouardBERGE/rasm) installed and then you can run the Makefile in the /sw/commonlib/cpc_asm area to generate the fiforsx.bin and fiforsx.rom files. Then go to /sw/examples and run the Makefile there to build a .dsk image which will include all the CPC BASIC programs and binaries.
On the Pi side, you need to have BBC BASIC for SDL installed on the full Raspbian. This recipe worked for me:
# Install SDL
sudo apt install libsdl2-dev -y
sudo apt install libsdl2-image-dev -y
sudo apt install libsdl2-mixer-dev -y
sudo apt install libsdl2-ttf-dev -y
sudo apt install libsdl2-ttf-2.0-0 -y
sudo apt-get install libsdl2-net-2.0-0 -y
sudo apt-get install mesa-utils -y
# Get BBC BASIC
mkdir BBCSDL
cd BBCSDL
wget https://www.bbcbasic.co.uk/bbcsdl/bbc-rpi.zip
unzip bbc-rpi.zip
cd ..
Once that's installed you can start BBC BASIC, picking Richard Russell's 'SLIDE' IDE option. Load the vdu.bas code and run it to see the VDU client running in an X window.
To run the client in full screen mode you need to save out the program as a tokenised version, vdu.bbc from the IDE. Quit the IDE and now you can run from the command line with
./bbcsdl vdu.bbc -fullscreen
(The command line will only accept the tokenised BASIC rather than the ASCII version).
Escape and *QUIT will exit the vdu client to get back to the Pi OS.
If you add this command line to your /etc/rc.local file then the Pi will boot up directly into the full screen vdu client on startup. No need to have keyboard and mouse connected to the Pi after that
One note on the Pi - BBC BASIC for SDL wasn't happy on my old Pi Zero V1.3 ('illegal instruction'), but runs fine on my 3A+ and Pi Zero W2.
Quote from: revaldinho on 10:18, 22 March 22Quote from: XeNoMoRPH on 06:58, 22 March 22fantastic news, so if I have understood it correctly to test it on my CPClink, I must run the example code in basic on my CPC6128 with the CPCLink expansion connected to my MX4 board, right? , and the pizero, connected to a monitor? , and where is file "fiforsx.bin" ? , thx :)
Yes, it's very much like running the loopback test. You need to start up the Pi with the vdu program running to set up the GPU client. Then load and run the CPC BASIC on the host.
All the sources are checked into git, but you do have to build the binaries. I'll copy them into a .dsk file and also provide the .bbc file (for the Pi) in this thread later today which will make it easier to get started.
Building from source you need rasm (https://github.com/EdouardBERGE/rasm) installed and then you can run the Makefile in the /sw/commonlib/cpc_asm area to generate the fiforsx.bin and fiforsx.rom files. Then go to /sw/examples and run the Makefile there to build a .dsk image which will include all the CPC BASIC programs and binaries.
On the Pi side, you need to have BBC BASIC for SDL installed on the full Raspbian. This recipe worked for me:
# Install SDL
sudo apt install libsdl2-dev -y
sudo apt install libsdl2-image-dev -y
sudo apt install libsdl2-mixer-dev -y
sudo apt install libsdl2-ttf-dev -y
sudo apt install libsdl2-ttf-2.0-0 -y
sudo apt-get install libsdl2-net-2.0-0 -y
sudo apt-get install mesa-utils -y
# Get BBC BASIC
mkdir BBCSDL
cd BBCSDL
wget https://www.bbcbasic.co.uk/bbcsdl/bbc-rpi.zip
unzip bbc-rpi.zip
cd ..
Once that's installed you can start BBC BASIC, picking Richard Russell's 'SLIDE' IDE option. Load the vdu.bas code and run it to see the VDU client running in an X window.
To run the client in full screen mode you need to save out the program as a tokenised version, vdu.bbc from the IDE. Quit the IDE and now you can run from the command line with
./bbcsdl vdu.bbc -fullscreen
(The command line will only accept the tokenised BASIC rather than the ASCII version).
Escape and *QUIT will exit the vdu client to get back to the Pi OS.
If you add this command line to your /etc/rc.local file then the Pi will boot up directly into the full screen vdu client on startup. No need to have keyboard and mouse connected to the Pi after that
One note on the Pi - BBC BASIC for SDL wasn't happy on my old Pi Zero V1.3 ('illegal instruction'), but runs fine on my 3A+ and Pi Zero W2.
Quote from: revaldinho on 10:18, 22 March 22Quote from: XeNoMoRPH on 06:58, 22 March 22fantastic news, so if I have understood it correctly to test it on my CPClink, I must run the example code in basic on my CPC6128 with the CPCLink expansion connected to my MX4 board, right? , and the pizero, connected to a monitor? , and where is file "fiforsx.bin" ? , thx :)
Yes, it's very much like running the loopback test. You need to start up the Pi with the vdu program running to set up the GPU client. Then load and run the CPC BASIC on the host.
All the sources are checked into git, but you do have to build the binaries. I'll copy them into a .dsk file and also provide the .bbc file (for the Pi) in this thread later today which will make it easier to get started.
Building from source you need rasm (https://github.com/EdouardBERGE/rasm) installed and then you can run the Makefile in the /sw/commonlib/cpc_asm area to generate the fiforsx.bin and fiforsx.rom files. Then go to /sw/examples and run the Makefile there to build a .dsk image which will include all the CPC BASIC programs and binaries.
On the Pi side, you need to have BBC BASIC for SDL installed on the full Raspbian. This recipe worked for me:
# Install SDL
sudo apt install libsdl2-dev -y
sudo apt install libsdl2-image-dev -y
sudo apt install libsdl2-mixer-dev -y
sudo apt install libsdl2-ttf-dev -y
sudo apt install libsdl2-ttf-2.0-0 -y
sudo apt-get install libsdl2-net-2.0-0 -y
sudo apt-get install mesa-utils -y
# Get BBC BASIC
mkdir BBCSDL
cd BBCSDL
wget https://www.bbcbasic.co.uk/bbcsdl/bbc-rpi.zip
unzip bbc-rpi.zip
cd ..
Once that's installed you can start BBC BASIC, picking Richard Russell's 'SLIDE' IDE option. Load the vdu.bas code and run it to see the VDU client running in an X window.
To run the client in full screen mode you need to save out the program as a tokenised version, vdu.bbc from the IDE. Quit the IDE and now you can run from the command line with
./bbcsdl vdu.bbc -fullscreen
(The command line will only accept the tokenised BASIC rather than the ASCII version).
Escape and *QUIT will exit the vdu client to get back to the Pi OS.
If you add this command line to your /etc/rc.local file then the Pi will boot up directly into the full screen vdu client on startup. No need to have keyboard and mouse connected to the Pi after that
One note on the Pi - BBC BASIC for SDL wasn't happy on my old Pi Zero V1.3 ('illegal instruction'), but runs fine on my 3A+ and Pi Zero W2.
The installation for the SDL libraries, many gave me errors, not sure yet if it matters.
The BBC BASIC works locally. Still in the process of setting up the dev environment.
Loopback test in BBCBASIC is next I guess, to make sure connectivity is working.
Yes, getting the simple loopback test to work is the first thing to do with the system to check comms between CPC and Pi. The CPC BASIC/Pi Python pairing is simplest (and lowest performance) to get going but once that's running then the CPCTelera/Pi C pairing is straightforward.
If you can start the BBC BASIC IDE on the PI then your SDL installation is probably good. The only real issue I had with it was finding it wouldn't run at all on my original Pi Zero where the older CPU wasn't supported.
In case anyone is interested PiHut now have Pi Zero Ws back in stock. I just replaced my Model B.
Quote from: Rabs on 21:45, 05 June 23In case anyone is interested PiHut now have Pi Zero Ws back in stock. I just replaced my Model B.
ooooh, they don't have stock of the Pi Zero version with pre-soldered header, unfortunately I messed up my Pi zero, the mini-HDMI connector. :-X
Quote from: XeNoMoRPH on 06:48, 06 June 23Quote from: Rabs on 21:45, 05 June 23In case anyone is interested PiHut now have Pi Zero Ws back in stock. I just replaced my Model B.
ooooh, they don't have stock of the Pi Zero version with pre-soldered header, unfortunately I messed up my Pi zero, the mini-HDMI connector. :-X
Oh yes sorry forgot to mention only available without the header at the moment. The Zero is a much better fit than my big Model B though.
20230606_103041.jpg
Are there actually applications for this hardware setup?
Or can we watch videos on ... somewhere?
(Could be a great promotion).
Quote from: GUNHED on 14:15, 06 June 23Are there actually applications for this hardware setup?
Or can we watch videos on ... somewhere?
(Could be a great promotion).
To be honest, I have not done a lot with it other than run the test programs. I keep getting distracted with other projects. But I would like to use it as a file store. At the moment I use Visual Code and the retro assembler to produce the binaries then create a disk then put this on a USB stick before plugging into a gotek. Would be neat to just load the binary up from the PI.
I am working on a couple of things that will come together and includes the use of the cplink card. The main issue i have with this so far is my unfamiliarity with the Pi and my 6128plus safety.