Discussion about connecting RASPI to QL

Nagging hardware related question? Post here!
Paul
Gold Card
Posts: 257
Joined: Mon May 21, 2012 8:50 am

Discussion about connecting RASPI to QL

Post by Paul »

This is a thread derived from "QL prototyping board..."
Dave wrote:There's are a couple of ways to do it. It depends if you just want to pass a. Yet back and forth or if you want to address a block of memory. It would need some hefty GPIO on the pi's side.

I'll email you in a bit and we can talk more about it.
As the GPIO is 3.3V and QL is 5V some interfacing has to take place.
For Example by using 74LVX245 ICs. Thats why I am so keen on any Information about buffered QL backplanes.
It's not easy to figure out the possible ways how the bus can be used (directionwise) because I guess while "normal" Adress lines are only read from BUS when using the expansion Slot this will change in case a GC or SGC will be used behind the Buffer.
Kind regards Paul


Derek_Stewart
Font of All Knowledge
Posts: 3928
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Discussion about connecting RASPI to QL

Post by Derek_Stewart »

Hi,

I was interested in the BBC Micro project PiTubeDirect, the project details are here:

https://github.com/hoglet67/PiTubeDirect/wiki

and a discussion thread on Startdot.org.uk

http://www.stardot.org.uk/forums/viewto ... =3&t=11325

I was going build a PiTubeDirect Interface for a BBC Master to connect the Raspberry PI via the Tube Interface on the BBC Micro.

I wondered if the same thing could be implemented on the Sinclair QL. The BBC Micro has a dedicated interface called the Tube which allows the BBC Micro to communicate with a second processor, or coprocessor.

The hardware side of the project looks to be completed for the BBC Micro with the 5v to 3.3v for Rapsberry PI GPIO interface translation. Connection to a Sinclair QL with the correct voltage translation could be achived, but I wondered about the software interface to Raspberry PI. The PiTubeDirect project uses a custom operating system written in ARM assembler with a 6502 software interface. I am not sure how the QL could interface with the ARM software, though a 68000 could in theory emulate a 6502 CPU at register level.

All thoughts are the moment, when I time I will build the PiTubeDirect for my BBC Micro.


Regards,

Derek
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Discussion about connecting RASPI to QL

Post by tofro »

Derek,

other than the Beep, the QL has no established history of co-processors. The first thing that in my opinion would need to be defined would be: What is it you want to achieve whith a co-processor? For the moment, I really don't see a lot of possible uses - If it's only hardware-emulating another CPU (like an MS-DOS emulator) and displaying on the QL screen, I really don't see much point in it. If we're looking at easier interfaces to a modern external world, like access to USB and networking, for example, I see a lot of potential.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Discussion about connecting RASPI to QL

Post by Dave »

Voltage translation is relatively straightforward, using either a bi-directional tri-state level shifter or using a more traditional buffer with direction control hung off the R/W line.

As for uses for this - I can think of several. You can use the video interrupt and use it to run code to copy out video RAM to a frame buffer, for example. The Pi3 can read 32k or 64k trivially during a period where the CPU is halted. It can read bytes at about 2 MBytes/sec full time, so 32k or 64k is not a problem in the interrupt period.

It can also be used as a smart ethernet interface - doing the SSL processing for us. It could be a USB gateway.

The main problem, as always, is originating the driver code.

I'm visiting Doug LaVerne in Oak Ridge, TN - a fellow QLer. When I get home on Wednesday or Thursday I'll read how it might be used and do a flexible board with all the building blocks in place so it's flexible and useful. No promises - I'm just a hobbyist - but it's not difficult to do something.


Timbucus
ROM Dongle
Posts: 49
Joined: Sat Apr 01, 2017 12:14 am

Re: Discussion about connecting RASPI to QL

Post by Timbucus »

Both,

You may also wish to look at the proposal for the ZX Spectrum Next http://www.specnext.com to add a rPI0 as a co-processor - if you are not already aware this is a Kickstarter to get an FPGA Spectrum remake that looks really nice (very QL like keys) - only 8 days to go but, it has blasted to over £500K. It is possible they may do a QL core at some point as well from chat on facebook.

Anyway onto the PI: It started out as a general expansion board for the Spectrum and especially for Victor's TBBBLUE firmware / Spectrum Clone (Next predecessor) combination called TK-Pie.

Then it became the method to provide HDMI out and the new video modes including sprites for the Next - as these are now implemented in hardware it has taken the role as primary delivery of USB support but, is still a general way to add functionality.

It uses a custom bare metal I.e. written in ARM assembly language and not a general Linux although that is probably still possible - that may need to use one of the Real Time distributions though due to limitations in the interfacing - NMI and HALT are not connected so it cannot control the Board.

The original TK-Pie project is here with open FPGA Verilog, ARM code and circuit designs etc:

https://gitlab.com/victor.trucco/TK-Pie

I suggest this as there will be a substantial user base and some developments for the PI I suspect - note that the do not intend going down that route for WiFi at the moment as the Next has an ESP8266 option for that.

Tim


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Discussion about connecting RASPI to QL

Post by Dave »

That was a nice little rabbit hole to fall down and lose four hours!

Looks like there's existing code to snoop memory. From reading this, it should be possible to snoop as much as 128k or 256k and just snoop writes capturing the address and what was written. So, we end up with a bitter compromise: the Pi has limited GPIO - not enough to grab 32 bits or even 16 bits and any decent address range. However, with a little ingenuity it should be possible to support full HD resolutions.

That said, if you use a windows system on your QL the memory footprint would be HUGE. That seems to be the main stumbling block - it's just not very practicable.

If I can make it so you can attach a Pi to the board, power it cleanly, and patch any GPIO to any QL pin with voltage translation... That leaves the experimenting up to you.


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Discussion about connecting RASPI to QL

Post by Dave »

Paul wrote:As the GPIO is 3.3V and QL is 5V some interfacing has to take place.
For Example by using 74LVX245 ICs. Thats why I am so keen on any Information about buffered QL backplanes.
It's not easy to figure out the possible ways how the bus can be used (directionwise) because I guess while "normal" Adress lines are only read from BUS when using the expansion Slot this will change in case a GC or SGC will be used behind the Buffer.
Kind regards Paul
With the R/W pin there it makes direction control easy. I personally prefer the TXB0108 because of the flexibility it provides (one PCB and Pi you can decide which GPIO are inputs or outputs and change them on the fly) but it is a bit pricy - $1.14 instead of $0.64 each. However, when only using 3 or 4 and having a very small run design like this, I think it's worth the extra expense. The TXB also performs better in this application.

If we treat this as a QL expansion device and give it a 16k decoded block, that would certainly increase options and make it a lot more flexible. If someone wants to do a simple GAL decoder and I focus on the PCB design?

My instinct is to make it a card that site the Pi just outside the QL, with ethernet and USB facing back and just hung off the edge of the card so you can use the usual spacers to mount the Pi securely. Do you want to be able to choose which GPIO go where, or is there a consensus of maybe....

8 bits data bus, 8 bits address bus (giving 256 byte addressable range), device select from address decoder, R/W line, room for 6 more GPIOs with 3x TXB0108 or all the remaining GPIO with 4x TXBs. Do you want a little thru-hole work area to maybe at sensors? Or bring out the SPI ports? Any other requests before I do a V1 of this?


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Discussion about connecting RASPI to QL

Post by Dave »

Just threw this together real quick to get an idea of the areas and spacings involved:
Quick drawing....
Quick drawing....
IC1-4 would be level shifters. All ports would be conveniently available outside the QL. I'd make a duplicate copy of the Pi connector so it would be easy to snoop traffic.

The 5V and 3V3 regulators would be 1117 SMDs. Their main heat transfer area is their power output pin. They have full over-current and thermal protection circuitry and are quite a bit more efficient than the 78XX regulators, as well as smaller.

If you combine this with a miniplane you can easily have a QubIDE/RAM card in the case too, which would be.... handy.

Am I missing anything important?


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Discussion about connecting RASPI to QL

Post by Dave »

Same again, but with dimensions and physical interactions shown:
36-24-36 *swoon*
36-24-36 *swoon*


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Discussion about connecting RASPI to QL

Post by Dave »

One thing this DOES allow is the Pi to operate the bus and snoop the QL IO area. It could read keyboard inputs, and read/write the microdrives, use the serial ports, etc. It could run uQLx, and use the QL's hardware as an accessory. It would be by far the most powerful BBQL ;)


Post Reply