CPC-CPLINK - a coprocessor interface card for all CPCs

[Prodatron]

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?

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.

[zhulien]

I found this, I will have a read

http://map.grauw.nl/resources/video/yamaha_v9990.pdf

[TotO]

Transparency. It can allows to overlay another video source.
And you have a perfect 5bit RGB cube for the colours palette.

[zhulien]

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

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

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

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

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

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

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

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

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

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.

[zhulien]

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

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 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:

Code Select Expand

# 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

Code Select Expand

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

 

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

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 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:

Code Select Expand

# 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

Code Select Expand

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

 

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

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 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:

Code Select Expand

# 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

Code Select Expand

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

[revaldinho]

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.

[Rabs]

In case anyone is interested PiHut now have Pi Zero Ws back in stock. I just replaced my Model B.

[XeNoMoRPH]

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

[Rabs]

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

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.

You cannot view this attachment.

[GUNHED]

Are there actually applications for this hardware setup?
Or can we watch videos on ... somewhere?
(Could be a great promotion).

[Rabs]

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

[zhulien]

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.