CPC-CPLINK - a coprocessor interface card for all CPCs

[revaldinho]

(BTW the 245s are from the level shifting LVC family rather than HCT types).

[eto]

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

[zhulien]

Do you have a quick start guide to setup the pi for pi-side dev?

[revaldinho]

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

[Rabs]

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.You cannot view this attachment.

[zhulien]

I saw one of the threads was about video steaming from the pi, what was the throughput?

[Animalgril987]

Has anyone set a CPLink up as a print server, ie to interface a CPC to a WiFi printer?

[revaldinho]

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

[zhulien]

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.

[revaldinho]

Hi Zhulien

First page of this thread has some snaps like this one showing a 3A+ on the back



and on the GitHub wiki there are full instructions, including this one showing a Zero.




If you haven't used it for a while then I just bring this section of the instructions 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.

[zhulien]

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.

[revaldinho]

At the pi side, what os do you recommend and are you using wiringpi?

In the sw/examples/loopback dir there are examples in C and Python using WiringPi and also Python using RPI.GPIO.

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.

There is currently no API to make it a multi-function peripheral. The GPU demo described in this post literally just sent bytes conforming to the BBC MIcro VDU stream spec (API) directly to the Pi, with the Pi running a client (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. 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.

[zhulien]

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

[genesis8]

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.

[Prodatron]

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

[zhulien]

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

[Prodatron]

The areaXXX ops sound good.
What colour depth is planned?

The windowXXX things would be too high level for SymbOS.

[zhulien]

The 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?

[zhulien]

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?

[TotO]

15 bit (+ 1 bit alpha) is more interresting than 16 bit I think.

[Prodatron]

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

[Prodatron]

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

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.

[zhulien]

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

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.

[zhulien]

How d

In 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?

[zhulien]

15 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?