Faster CPU plug in extensions, How?

A place to discuss general QL issues.
User avatar
Ruptor
Gold Card
Posts: 418
Joined: Fri Dec 20, 2019 2:23 pm
Location: London

Re: Faster CPU plug in extensions, How?

Post by Ruptor »

Dave wrote:A Pi is not fast enough at memory mapped IO to keep up with the QL's bus speed. Nor does it have enough continuous MMIO to make a sufficient sized word to make transfers efficient.
I hear what you are saying from your experience but I don't understand how an 800 MHz cpu can't keep up with an 8 MHz and not sure what MMIO has to do with it? There might be a problem with the number of IO lines on the RPi but a speed problem. :? I suppose an experiment would answer the question so I shall have a think.


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

Re: Faster CPU plug in extensions, How?

Post by Derek_Stewart »

Hi,

It is more likely that there is one one to write the low level device drivers on the QL and Raspberry Pi.

This has been done on a BBC Micro, by using the Tube interface and lot of ARM assembler.codr to make the system work.

What benefits do look for if a Raspberry Pi could be interfaced with a QL?


Regards,

Derek
User avatar
Ruptor
Gold Card
Posts: 418
Joined: Fri Dec 20, 2019 2:23 pm
Location: London

Re: Faster CPU plug in extensions, How?

Post by Ruptor »

Derek_Stewart wrote:What benefits do look for if a Raspberry Pi could be interfaced with a QL?
Same as any other super charging board speed & RAM plus HDMI, USB and SD card for starters all at very low cost. :) How much quicker is an RPi Linux emulator than the real QL? I saw some figures somewhere but can't remember. :roll:


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Faster CPU plug in extensions, How?

Post by Peter »

Ruptor wrote:I hear what you are saying from your experience but I don't understand how an 800 MHz cpu can't keep up with an 8 MHz and not sure what MMIO has to do with it? There might be a problem with the number of IO lines on the RPi but a speed problem.
Firstly, the RPi GPIO, SPI etc. are unproportionally slow, even a standard >50 MHz microcontroller is better in those diciplines. You can not judge things by clock rates etc. but must take into account the gaps between accesses. Secondly, even if the RPi had good throughput on the GPIO connector (which it has not) one needs "hard" realtime performance to emulate a CPU. Which means it must always meet timing constraints under all circumstances, not just in 99.9% of the circumstances. Here comes the second problem, as the RPi usually needs to run an OS to meet expectations. Programming a "hard" realtime system on a bare metal basis is not an easy task, and very restrictive when it comes to the features people are used to from Linux.

(I just say "hard" realtime to make clear that I mean realtime. "Soft" realtime is no realtime, but many don't fully understand that matter.)


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

Re: Faster CPU plug in extensions, How?

Post by Derek_Stewart »

Hi,

I think that writing an QL emulator, which is writen in C, ported to the RPi is one thing.

Converting the QL emulator to a "Bare Metal" emulator is another totally difference problem. Which I mean, the C code must be re-written in ARM assembly code, which I do not see many people in the RPi world interested in ARM assembler.

In addition to this, how many users of the RPi would take advantage of this type of "Bare Metal" ARM application.

Personally, I like assembly code, but I lack the creativity to perform it correctly.

But I am prepared to have a go, do not expect anything soon, as I am only beginning in ARM assembly programming.


Regards,

Derek
User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

Re: Faster CPU plug in extensions, How?

Post by Pr0f »

I think the issue with the pi is that despite it's speed and graphics - getting it to behave as an accessory such as a video card would not be workable because you can't get memory updates for the emulated QL screen in fast enough.

If the PI took on more of the role of a QL to avoid this issue - using it's own RAM / CPU etc, it would then need to emulate the QL at a hardware level or software level - the software emulation has been done - but making a hardware emulation is a massive amount of work for how many people?


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Faster CPU plug in extensions, How?

Post by Peter »

Derek_Stewart wrote:Converting the QL emulator to a "Bare Metal" emulator is another totally difference problem. Which I mean, the C code must be re-written in ARM assembly code, which I do not see many people in the RPi world interested in ARM assembler.
It could still be in C, but once you go "bare metal" most of the luxury is gone.

(When I mentioned emulation in my previous post, I was referring to hardware emulation of the 68008 by the way. Pure software emulation would at least not suffer from the realtime issues.)


User avatar
Ruptor
Gold Card
Posts: 418
Joined: Fri Dec 20, 2019 2:23 pm
Location: London

Re: Faster CPU plug in extensions, How?

Post by Ruptor »

Derek_Stewart wrote:Personally, I like assembly code, but I lack the creativity to perform it correctly.But I am prepared to have a go, do not expect anything soon, as I am only beginning in ARM assembly programming.
These days optimising compilers are just as good as assembler so it is best to learn how to tweak the compiler to give you what you want.
I asked about RPi bit bashing a while ago for another project and the answer was a maximum of about 25 to 30 MHz which I guess is your point about the I/O being slow but it is still fast enough I think. The timing only has to be critical for each 68K instruction to QL it wouldn't matter if the processor hung around for 1uS in between and it wouldn't matter if the RPi hung around, interrupts disabled, for each instruction since it can easily catch up. I don't know anything about the critical timing points on the QL like you guys do so if you would like to suggest the worst case timing situation I could use that as a test point and see if I have any chance of doing it on an RPi.


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

Re: Faster CPU plug in extensions, How?

Post by Derek_Stewart »

Hi,

If you are okay with C compiled programmes, then there are 2 QL emulators already, just download the source and compile the emulator.

I do not know how to use the GPIO pins, but I guess it is more mapped.


Regards,

Derek
User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Faster CPU plug in extensions, How?

Post by mk79 »

Did exactly that https://www.kilgus.net/2019/04/21/ql-vga-part-1/ and eventually went another route. It can work, mostly because the ARM-CPU your code runs on is actually only a secondary CPU, the hard part of the hardware initialization including loading of the kernel from SD is done by a master CPU that is part of the chipset. But still, doing hard realtime with a Pi is difficult to program and very badly documented. Also, most PIs don't have enough pins for all bus signals. Also, you need a bunch of voltage converters, of course.


Post Reply