Faster CPU plug in extensions, How?

A place to discuss general QL issues.
User avatar
Ruptor
Trump Card
Posts: 177
Joined: Fri Dec 20, 2019 2:23 pm

Re: Faster CPU plug in extensions, How?

Postby Ruptor » Tue Sep 15, 2020 12:02 am

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
QL Wafer Drive
Posts: 1917
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Faster CPU plug in extensions, How?

Postby Derek_Stewart » Tue Sep 15, 2020 12:06 am

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
Trump Card
Posts: 177
Joined: Fri Dec 20, 2019 2:23 pm

Re: Faster CPU plug in extensions, How?

Postby Ruptor » Tue Sep 15, 2020 12:49 am

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: 1075
Joined: Sat Jan 22, 2011 8:47 am

Re: Faster CPU plug in extensions, How?

Postby Peter » Tue Sep 15, 2020 8:30 am

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
QL Wafer Drive
Posts: 1917
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Faster CPU plug in extensions, How?

Postby Derek_Stewart » Tue Sep 15, 2020 9:10 am

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
Super Gold Card
Posts: 659
Joined: Thu Oct 12, 2017 9:54 am

Re: Faster CPU plug in extensions, How?

Postby Pr0f » Tue Sep 15, 2020 10:31 am

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: 1075
Joined: Sat Jan 22, 2011 8:47 am

Re: Faster CPU plug in extensions, How?

Postby Peter » Tue Sep 15, 2020 10:32 am

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
Trump Card
Posts: 177
Joined: Fri Dec 20, 2019 2:23 pm

Re: Faster CPU plug in extensions, How?

Postby Ruptor » Tue Sep 15, 2020 11:22 am

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
QL Wafer Drive
Posts: 1917
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Faster CPU plug in extensions, How?

Postby Derek_Stewart » Tue Sep 15, 2020 11:42 am

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
Super Gold Card
Posts: 642
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Faster CPU plug in extensions, How?

Postby mk79 » Tue Sep 15, 2020 12:27 pm

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.



Who is online

Users browsing this forum: No registered users and 3 guests