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

Re: Discussion about connecting RASPI to QL

Postby Paul » Wed May 24, 2017 6:19 am

This looks like the start signal for my GAL equations ;)
About the CLK brought through to PI: I think its better to tell the PI what to do instead of having it decide things because of own analysis.
about clk speed, i'd prefer to use one of the 16K "registers" for passing this info
Having /SEL and /OE on seperate pins seems to be a good idea. I guess I would have forgotten about this.
About the adress strobe, I prefer not to give this to the PI but instead have /SEL with useful timing.

All this seems to be an interface so the QL can read or write things from/to the PI.
Do you think its possible to have the PI interrupt the QL as well?
Like if network traffic is incomming, mouse movement, Keyboard presses, RFID chip reads...?
Could this be done?
Kind regards
Paul


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

Re: Discussion about connecting RASPI to QL

Postby Dave » Wed May 24, 2017 6:37 am

I don't think USB will ever be accessible because of the way it's structured. Ethernet might be possible, but it would be a fraction of the speed of the CP2200 that Peter Graf and me have used. I think we're standardizing around that.

One fun thing might be to include a 16K ROM socket. You could have a ROM image there if you wanted, and not if you didn't. Even if you had the ROM there, you could still read and write to the Pi through a hole in the ROM image.

I suspect the best use the Pi could be put to is as a video frame buffer with full HD output. If all writes to screen RAM were trapped and copied to the Pi.... Just have it shadow video memory. You could have a 64k or 128k area shadowed and gain a LOT of flexibility over video. If that actually works, it would be a no-brainer to put a Pi Compute Module on QL2. If this is a possibility, maybe I should take two or three more address lines through? That allows 64 or 128K to be shadowed.

It is entirely possible that a Pi's GPIO could operate microdrives and floppies (floppies have been done) so it wouldn't take too much work to make a Pi hat for QL keyboard and etc. I know some want a real CPU, but it would make a fast and capable QL clone with lots of memory and nice video for a fraction of the cost.

It could be a math co-processor. It could be an X-server for a new windowing system. It could be a print buffer (Rich might be interested in that!) Even if Ethernet didn't work, it could act as an SSL proxy for a CP2200. Encryption. JPEG conversion. The possibilities are almost as great as what you can do with a QL in the first place.


Paul
Gold Card
Posts: 257
Joined: Mon May 21, 2012 8:50 am

Re: Discussion about connecting RASPI to QL

Postby Paul » Wed May 24, 2017 6:43 am

I am not shure if ths was intended as an answer to my last post/question :oops:


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

Re: Discussion about connecting RASPI to QL

Postby Dave » Wed May 24, 2017 6:57 am

It is, but at the general "oooh think of the possibilities" level instead of the "ok, we'll need this, this and this" level.


Paul
Gold Card
Posts: 257
Joined: Mon May 21, 2012 8:50 am

Re: Discussion about connecting RASPI to QL

Postby Paul » Wed May 24, 2017 6:58 am

Anyway, if there are unused GPIO pins on the PI I would definitely fill them with address lines as far as possible.
Your estimation is that the PI would be to slow to host the ROM Image you want to read by the QL?
I am thinking about the possibilities of the PI like read/write to SD Cards or USB disks in whatever file format thinkable of.
About having the file blocks in PI RAM instead of QL RAM giving "unlimited" file numbers or disk images IF a filesystem driver would be written to use on the QL.
Am I on a completely wrong path?


Paul
Gold Card
Posts: 257
Joined: Mon May 21, 2012 8:50 am

Re: Discussion about connecting RASPI to QL

Postby Paul » Wed May 24, 2017 7:06 am

Dave wrote:It is, but at the general "oooh think of the possibilities" level instead of the "ok, we'll need this, this and this" level.

I was not thinking about adding USB to the QL but to use a specialized USB part.
I don't think its possible for the QL to recognize the USB devices but its possible to have a mouse attached (and handled) to the PI and give mouse positions to the QL in an abstract way, not at USB level.
Same with file handling. I'd like the QL to ask for a directory content attached to a handle (e.g. one of 255 file handles). The PI does the work and the QL can read the Information etc.
If a path is disconnected from the PI then an interrupt to the QL should be passed to all the open handles on that device so the corresponding jobs on the QL know their files are unaccessible from now on.


Paul
Gold Card
Posts: 257
Joined: Mon May 21, 2012 8:50 am

Re: Discussion about connecting RASPI to QL

Postby Paul » Wed May 24, 2017 7:11 am

Don't you think we should move this "software" discussion into an own thread and concentrate on the hardware aspect here?
Can an admin move these parts please?


Nasta
Trump Card
Posts: 204
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: Discussion about connecting RASPI to QL

Postby Nasta » Mon May 29, 2017 9:33 pm

I am sorry to say there is a lot of wishful thinking going on in this thread.

There are two areas of contention:
1: if you want to use something else on the QL bus instead of the fitted CPU, the appropriate protocol for this has to be used, involving BGL and BRL lines. This is only possible on a bare QL. GC/SGC already use this to disable the original 68008 CPU entirely, by permanently tying BRL low. There is no way to get to the internals of the GC/SGC as there is no way to disable the CPU on them AND the data and address buffers are not reversible.
2: Once you remove the CPU from the bus, you MUST make your hardware behave as much as possible just like the original CPU because all the rest of the hardware expects this. Simply put: refer to the 68008 databook. If buffers are present, they need to go to the RasPI side to handle 3V3 to 5V conversion. Relevant signals to emulate are obviously A0..A19, D0..D7, RDWL, DSL, and DTACLK.

Perhaps the third area of contention is, what kind of a performance one can expect - adding yet another bus master WILL make things slower, and since the bus is slow to begin with, make that VERY slow. For instance, it is _barely_ possible to transfer the entire 32k contents of the screen in 'real time' and that is with ZERO time left to the 68008.

Because of this, a co-operative approach might be a better idea. There is such a thing as a dual port RAM. A small amount would be enough, perhaps 2k. This RAM is interesting because it is sapable of simultaneous access to the same memory array from two completely separate sides. The only contention can happen if the two sides attempt to simultaneously write the same byte, and in this case a lockout is implemented in the RAM chip so that one side always wins. Such a dual port communications buffer can easily be used to pass IO data, assuming some driver software is present on both sides.

As for the screen, this is a bit harder nut to crack, but not impossible. One way is again dual port RAM, which would be larger in size (to cover the whole screen, 32k) and on the QL side connected as shadow RAM to the actual screen RAM (so the CPU would write data to real screen RAM in parallel with the shadow dual port RAM). RasPI would then simply read and process if necessary on it's own end as it sees fit.
The down-side is that larger capacity dual port RAM is expensive.
Another option could be 'dual porting' a regular static RAM of high enough speed. There is a bit of multiplexing using HC chips involved but it is doable. In this case memory size is MUCH less of a problem.
Both of the above approaches can work with more advanced systems than the regular bare QL.


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

Re: Discussion about connecting RASPI to QL

Postby Dave » Thu Jun 01, 2017 5:22 am

I think there's a lot of daydreaming in the possible future scope of projects. We're just shooting the breeze.

I think the Pi3 is capable of passively observing the bus as a minimum. It should be able to follow what address the CPU is reading or writing and what data was moved. The Pi3 is fast enough to follow all writes in a 32K block and to recreate what's happening (video frame store) and if it can do that, there's lots of other things it can do. With some careful and considered interfacing and well written software, it might be possible to do a bit more.

A LOT of work, though ;)


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

Re: Discussion about connecting RASPI to QL

Postby Dave » Fri Jun 09, 2017 4:15 pm

So here's what I'm going to do:

I'm going to set this up with 4x 74LVX245s on it. All with have the low side connected to a Pi header, and the high side uncommitted. There will be a small jumper area so you can connect any GPIO to any QL bus pin.

I'll offer the bare card, cards with just the SMD mounted or fully assembled cards with a bunch of jumpers. The card will be well labeled, and will also have a small hardware prototyping area.

I will proceed with the prototyping card separately. More in a short while.



Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 4 guests